Skip to main content

Overview

AI Apply is asynchronous by design. Parsing a job posting and submitting an application both run in the background. AI Apply provides two webhooks so that you do not need to poll for results:
  • The data-changed webhook notifies you that job postings in your environment changed. Fetch the changes with the updated_after filter to keep postings and application forms current.
  • The application updated webhook reports the outcome of a single application and includes the application in its payload.
First time implementing Kombo webhooks?View our general Webhooks guide for delivery, signature validation, retries, and other behavior shared by every Kombo webhook.

Data-changed webhook

Strategy

Perform one full fetch of your job postings, then fetch only the changes whenever the data-changed webhook arrives. The webhook signals that data changed. The updated_after filter limits the response to changes since your previous fetch.

The data-changed webhook

Kombo sends ai-apply-data-changed when one or more job postings in your environment changed in a customer-facing field: availability, archival, URL, job code, career site, or the application form. This includes a posting finishing parsing, a bulk import archiving postings, and a re-parse producing a new application form. The payload names the changed model, not the changed records. The webhook is a notification, not a data delivery. Fetch the relevant endpoint after receiving it.
The webhook is debounced with a 30-second window. The first change is delivered immediately. Changes within the following 30 seconds are batched into a single webhook, which starts the next window. You receive at most one webhook per 30 seconds, and none while no data changes.
changed_models covers job postings only. Application outcomes are not delivered through this webhook. They are delivered through the application updated webhook, which includes the application itself, so no follow-up fetch is required.

Configuring the webhook

Create the webhook in the Kombo Dashboard under Configuration, Webhooks. Select the type AI Apply: Data changed, enter a label, and enter the URL Kombo should call.
Creating the AI Apply data-changed
webhook
Every webhook is signed with the signing secret shown on the same page. See Validate the data for how to verify the signature.

Fetching changes with updated_after

Both job posting endpoints accept an updated_after query parameter in ISO 8601 format. The response includes every posting whose updated_at is equal to or later than the given timestamp. Delta fetches are especially important for GET Job Postings Forms. Application forms are large, so the endpoint returns at most five postings per page, and fetching an entire catalogue requires many requests. A delta after a webhook typically fits in one. Which endpoint to sync depends on how you obtain application forms: Both guides document the response shapes in detail.

Keeping track of the timestamp

Use the start time of your previous fetch as the updated_after checkpoint, not the latest updated_at value in its results. This is the same method used for the Unified API.
  1. Record the current UTC time immediately before requesting the first page.
  2. Follow next until it is null, keeping every filter unchanged between pages.
  3. Once every page has succeeded, store the recorded start time as the new checkpoint.
  4. On the next fetch, pass that checkpoint as updated_after.
  5. Upsert results by posting id.
Recording the start time ensures that a posting changed while you were paging is included in the next delta. Advancing the checkpoint only after all pages succeed ensures that a failed fetch is repeated in full and no change is skipped. Both properties, together with the inclusive comparison, mean that the same posting can be returned more than once. Upserting by posting id handles this without additional logic.

Job Posting Updated Webhook

The ai-apply-job-posting-status-updated webhook is deprecated. Use the data-changed webhook together with updated_after instead. It still fires for existing setups, but do not build on it.

Lifecycle

If a parse attempt fails but a previous successful revision still exists, the posting remains APPLYABLE.

Payload

The payload matches the job posting schema you receive from the get job posting endpoint. Examples
  1. A job posting was successfully parsed.
  1. A job posting failed to parse.
  1. A job posting was taken offline.

Handling job posting availability changes

A job posting’s availability field may switch from being non-applyable to applyable, and vice versa. As soon as this changes, you should update your UI accordingly. We recommend either hiding the job from the list of jobs you display to candidates or showing the job URL directly for the candidate to apply on the career site.
Most transitions from being applyable to non-applyable are caused by a job posting being archived. In rare cases, a job posting’s application form may change, triggering a re-parse.

Application Updated Webhook

Lifecycle

When can an application be marked as FAILED?If the candidate input is fundamentally invalid, and Kombo has no chance to submit the application in the candidate’s name without the candidate providing more information, the application will be marked as failed. In the future, Kombo may support flows of following up with the candidate to collect remaining data in an automated manner.In rare edge cases, when a job is taken offline while an application is in-flight, the application will also be marked as failed.

Payload

The payload follows the application schema you receive from the get application endpoint. Examples
  1. Application is automatically submitted
  1. Application is submitted after Kombo QA
  1. Application is marked as failed by Kombo QA (e.g., invalid candidate input)