Jobs Deleted API Endpoint Documentation

Table of contents

Introduction

The Jobs Deleted endpoint provides a durable feed of job postings that were permanently deleted from the jobdata database. It is designed for downstream systems that maintain a local copy of job data and need to remove listings when they are no longer available in the API.

This endpoint is different from the Jobs Expired endpoint. Expiration describes the lifecycle state of a job posting while it remains in the database. The Jobs Deleted records jobs that have been removed permanently and exposes enough identifying information for a client to find and delete the corresponding local record.

The endpoint does not provide a single-job detail route. Use the job_id in a deletion record to identify the job in your local system. The job itself is no longer available from /api/jobs/ after deletion.

Endpoint Overview

Endpoint: /api/jobsdeleted/

Method: GET

Authentication: Yes

Description: Retrieves a list of all jobs that have been removed form the jobdata API database permanently. The feed is especially useful for search indexes, job boards, data warehouses, analytics pipelines, and other integrations that synchronize job records over time.

Request

Send requests to the endpoint with the API key in the Authorization header.

Using curl

curl -G "https://jobdataapi.com/api/jobsdeleted/" \
  -H "Authorization: Api-Key YOUR_API_KEY" \
  --data-urlencode "page_size=1000"

Using Python

import requests

url = "https://jobdataapi.com/api/jobsdeleted/"
headers = {"Authorization": "Api-Key YOUR_API_KEY"}
params = {"page_size": 1000}

response = requests.get(url, headers=headers, params=params, timeout=45)
response.raise_for_status()
data = response.json()

for deletion in data["results"]:
    print(deletion["sequence"], deletion["job_id"])

Access and Pagination

A valid API key enables the full paginator. The default page size is 200 records, and page_size accepts values from 1 through 4000. Standard page-number parameters are also available:

• page: Selects a page of results. This requires an API key.
• page_size: Sets the number of results per page, from 1 through 4000. This requires an API key.
• after: Restricts results to records where after < sequence. This requires an API key and must be a non-negative integer.
• change_id: Returns only records whose change_id exactly equals the supplied value.

Results are ordered by descending sequence, so the newest deletion records appear first. sequence is an ever-increasing cursor assigned when a deletion is recorded. The after parameter is an exclusive lower-bound filter: for example, after=1200 returns records with sequence values greater than 1200, still ordered from highest sequence to lowest sequence.

The change_id comparison is exact. It is useful when a known import, correction, or administrative operation needs to be audited or synchronized separately. It is not a partial-text or case-insensitive search.

For a normal incremental synchronization, store the greatest sequence value successfully processed by your integration. On a later request, send that value as after and process the returned records. Advance the stored cursor only after the corresponding local deletions have completed successfully.

Anonymous Requests

Without an API key, the endpoint permits the default first page only. The anonymous page is limited to 100 records. Requests using page, page_size, or after require an API key with an access subscription and return a permission error without one.

Response Structure

The endpoint uses the standard paginated response format:

• count: The total number of matching deletion records.
• next: A URL for the next page, or null when there is no next page.
• previous: A URL for the previous page, or null on the first page.
• results: An array of deletion records.

Deletion Record Fields

Each item in results contains the following fields:

• sequence: A unique, monotonically increasing integer assigned to the deletion record. Use this value as the synchronization cursor.
• job_id: The integer ID of the deleted job in the jobdata API.
• ext_id: The external job identifier, when the source supplied one. This value may be null.
• company_id: The integer ID of the company associated with the deleted job.
• source_id: The integer ID of the ATS or source associated with the deleted job.
• application_url: The application URL stored on the job at deletion time.
• published: The original publication timestamp of the job, or null when it was not available.
• deleted_at: The timestamp at which the deletion record was created, in ISO 8601 format.
• change_id: An optional operation identifier supplied when the deletion was performed. It may be null when no identifier was provided.

Example Response

{
  "count": 2,
  "next": null,
  "previous": null,
  "results": [
    {
      "sequence": 1202,
      "job_id": 987654,
      "ext_id": "ats-4567",
      "company_id": 321,
      "source_id": 14,
      "application_url": "https://example.com/jobs/ats-4567/apply",
      "published": "2026-08-15T09:30:00Z",
      "deleted_at": "2026-08-16T10:45:12.123456Z",
      "change_id": "bad-import-2026-08-16"
    },
    {
      "sequence": 1201,
      "job_id": 987653,
      "ext_id": null,
      "company_id": 321,
      "source_id": 14,
      "application_url": "https://example.com/jobs/ats-4566/apply",
      "published": "2026-08-15T08:15:00Z",
      "deleted_at": "2026-08-16T10:45:12.123456Z",
      "change_id": null
    }
  ]
}

Synchronization Example

The following example keeps a local deletion cursor and removes each matching job from a local store. The cursor is advanced only after the response has been processed successfully.

import requests

API_URL = "https://jobdataapi.com/api/jobsdeleted/"
API_KEY = "YOUR_API_KEY"
last_sequence = 1200

response = requests.get(
    API_URL,
    headers={"Authorization": f"Api-Key {API_KEY}"},
    params={"after": last_sequence, "page_size": 1000},
    timeout=45,
)
response.raise_for_status()
data = response.json()

for deletion in data["results"]:
    local_jobs.delete_by_job_id(deletion["job_id"])

if data["results"]:
    last_sequence = max(
        deletion["sequence"] for deletion in data["results"]
    )
    save_last_sequence(last_sequence)

For a large backlog, use the next URL from the paginated response until it becomes null. Keep the cursor update and local deletion work durable so that a failed request or interrupted process can be retried safely.

Deletion Sources

Deletion records are created when jobs are permanently removed through our internal job deletion workflow. A deletion record includes a snapshot of the job identifiers and source metadata needed for downstream cleanup. Here the optional change_id value can be supplied to group related deletions. For example, a correction run might use bad-import-2026-08-16 for every affected job. Querying change_id=bad-import-2026-08-16 then returns exactly the records assigned to that operation.

Notes and Recommendations

• Replace YOUR_API_KEY with an API key from your dashboard.
• Treat sequence as an opaque integer cursor. Do not derive it from job IDs or timestamps.
• Store the greatest successfully processed sequence value and make local deletion operations idempotent.
• Use change_id for targeted audit or correction workflows, not as a replacement for the sequence cursor.
• Preserve ext_id, company_id, and source_id when useful for reconciling records across systems.
• A deletion record is a notification that the job was removed; it is not a replacement for a full historical job archive.
• Do not assume that deleted_at is the same as the original source ATS removal time. It is the time the deletion was recorded in our database.

This endpoint gives you a compact and reliable way to remove stale job records from downstream systems while retaining the source and operation context needed for auditing.

Related Docs