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 withremote_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 aremote_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).
Integration setup errors now return HTTP status code 409 instead of 503
From Tuesday, May 19, 2026, the following Kombo error codes will start returning HTTP409 Conflict instead of HTTP 503 Service Unavailable:We’re making these changes in accordance with our error handling best practices 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) 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.codefield instead of the HTTP status code, so it keeps behaving correctly once these errors start returning409.
INTEGRATION.SETUP_INCOMPLETE, INTEGRATION.SETUP_SYNC_PENDING, and INTEGRATION.QA_FAILED if you don’t have it yet:INTEGRATION.SETUP_INCOMPLETEandINTEGRATION.QA_FAILEDshould be surfaced to the affected end-customer or admin user because they usually require manual intervention.INTEGRATION.SETUP_SYNC_PENDINGresolves once the initial sync finishes, but initial syncs can take hours in some cases. We recommend relying on webhooks instead of retrying silently or polling aggressively.
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 HTTP429 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_EXCEEDEDerror code in your retry logic. - Use exponential backoff starting at ~1s.
- Optionally, check the
Concurrency-Remainingresponse header to throttle proactively.