> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kombo.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Important Changes

> Significant platform changes that may affect your integration.

<Update label="2026-07-21" description="Timesheet retention outside the sync window">
  ## Timesheets that age out of the sync window are no longer marked as deleted

  Kombo only keeps a rolling window of timesheets up to date during sync (default: the last **2 months**, configurable via the **"Historical timesheet months to sync"** setting). Previously, timesheets that fell outside that window were marked as deleted on the next full sync.

  **What changed:** Kombo now only deletion-tracks timesheets **inside** that window. Timesheets that age out of the window are **kept** and are not marked with `remote_deleted_at` just because they were not re-fetched. Within the window, timesheets that disappear from the remote HRIS are still marked as deleted as usual.

  ### Who is affected

  Anyone relying on timesheets outside the window receiving a `remote_deleted_at` value (or disappearing from default list responses) simply because they aged out of the re-fetch window.

  ### What you should do

  * Treat aging out of the window as **retention**, not deletion — do not expect those rows to be marked deleted.
  * If you need history beyond what you've kept up to date, configure a larger window upfront or archive timesheets on your side.
  * Contact Kombo support if you need the window changed for your environment (the setting is read-only in the dashboard).

  See the [Time & Attendance guide](/hris/features/time-and-attendance) and the [GET timesheets](/hris/v1/get-timesheets) endpoint for details.
</Update>

<Update label="2026-05-19" description="New HTTP status code for integration setup errors">
  ## Integration setup errors now return HTTP status code 409 instead of 503

  From **Tuesday, May 19, 2026**, the following [Kombo error codes](/guides/errors) will start returning **HTTP `409 Conflict`** instead of **HTTP `503 Service Unavailable`**:

  | Error code                                                                        | Meaning                                                      |
  | --------------------------------------------------------------------------------- | ------------------------------------------------------------ |
  | [`INTEGRATION.SETUP_INCOMPLETE`](/guides/errors#integration-setup_incomplete)     | The integration setup hasn't been finished yet.              |
  | [`INTEGRATION.SETUP_SYNC_PENDING`](/guides/errors#integration-setup_sync_pending) | The initial sync after connection is still running.          |
  | [`INTEGRATION.QA_FAILED`](/guides/errors#integration-qa_failed)                   | The integration's setup data didn't pass our quality checks. |

  We're making these changes in accordance with [our error handling best practices](/guides/errors#error-format) that we announced with the release of structured error codes in August 2025:

  Error handling logic on top of the Kombo API should, if available, **always make use of the `error.code` field** in the response, and **only** fall back to the HTTP status code if the `error.code` is not present (which should rarely happen).

  We're changing these specific codes because `409 Conflict` ([RFC 7231](https://www.rfc-editor.org/rfc/rfc7231#section-6.5.8)) matches the actual error state better. The `error.code` values themselves are **not changing**.

  ### What you should do

  Start by checking whether your implementation currently branches on the HTTP status code (`503` specifically, or `5xx` in general) when handling any of the three error codes above.

  * **If it doesn't, you're all set** and don't need to take any action.
  * **If it does**, please update that logic to rely on the `error.code` field instead of the HTTP status code, so it keeps behaving correctly once these errors start returning `409`.

  While you're at it, you may want to consider adding explicit handling for [`INTEGRATION.SETUP_INCOMPLETE`](/guides/errors#integration-setup_incomplete), [`INTEGRATION.SETUP_SYNC_PENDING`](/guides/errors#integration-setup_sync_pending), and [`INTEGRATION.QA_FAILED`](/guides/errors#integration-qa_failed) if you don't have it yet:

  * `INTEGRATION.SETUP_INCOMPLETE` and `INTEGRATION.QA_FAILED` should be surfaced to the affected end-customer or admin user because they usually require manual intervention.
  * `INTEGRATION.SETUP_SYNC_PENDING` resolves once the initial sync finishes, but initial syncs can take hours in some cases. We recommend relying on [webhooks](guides/webhooks) instead of retrying silently or polling aggressively.
</Update>

<Update label="2026-03-20" description="Concurrency limiting enforced">
  ## Action concurrency limiting is now enforced

  Kombo now enforces concurrency limits on action endpoints. Previously,
  concurrent requests were measured but not rejected. Now, when more than 30
  action requests are in flight simultaneously for a single integration,
  additional requests are rejected with HTTP `429` and the error code
  `PLATFORM.CONCURRENCY_LIMIT_EXCEEDED`.

  **Who is affected:** Customers sending many parallel action requests (e.g.,
  bulk-creating candidates or moving applications) may start receiving `429`
  responses they were not receiving before. Model read endpoints are not affected
  (e.g. `GET /ats/candidates`)

  **What to do:**

  * Handle the new `PLATFORM.CONCURRENCY_LIMIT_EXCEEDED` error code in your
    retry logic.
  * Use exponential backoff starting at \~1s.
  * Optionally, check the `Concurrency-Remaining` response header to throttle
    proactively.

  See the full [Concurrency Limiting](guides/concurrency-limiting) guide for
  details.
</Update>