Skip to main content
Fetch a candidate’s files from the ATS on demand, or have Kombo sync every candidate’s files into your own bucket.

Which one to use

On-demand fits when you need the files of a few candidates at a time. For the CVs of all your candidates, use synced. Doing that on demand means one request per candidate, each counting against the ATS rate limit, and you have to queue and retry them yourself.

On-demand attachments

Get candidate attachments returns all files of a candidate. Get application attachments returns the files of one application, or the candidate’s files if the ATS doesn’t store them per application. Both call the ATS when you ask and return a data_url that stays valid for 7 days. Both need the Read document attachments permission in your scope configuration.

Synced attachments

Synced attachments are in beta and available on the Enterprise plan, for a limited set of integrations so far (see the endpoint reference). Reach out to your account manager or support to enable them for your environment.
During the sync, Kombo lists each candidate’s attachments, downloads the files it doesn’t hold yet and writes them into your bucket. An attachment shows up in the API once its file is stored, so every attachment you read points to a file that exists.

Setup

Once enabled, we connect your bucket together with you and turn on the attachments model for your environment. On your side, enable the Read document attachments permission in your scope configuration.

Reading synced attachments

Get attachments returns each attachment with a content_ref pointing to its file in your bucket:
content_ref.key is the full object key, including your prefix, so read the file with it directly. application_id is null when the ATS files the attachment under the candidate rather than one application. Use updated_after to only fetch new attachments, and candidate_ids or application_ids to narrow them down. Filtering by application_ids excludes files that hang off the candidate directly.

What lands in your bucket

Each object keeps the original file name and content type, and carries the Kombo IDs as object metadata: kombo-attachment-id, kombo-candidate-id, kombo-integration-id, and kombo-application-id when the file belongs to an application.

Deletions

When an attachment or its candidate is deleted in the ATS, or the candidate falls out of your upstream filter, the attachment gets a remote_deleted_at (pass include_deleted=true to see it). 14 days later Kombo removes the file from your bucket and anonymizes the attachment. Deleting an integration removes its whole folder after the same 14 days.

Supported storage

Any S3-compatible storage works: Amazon S3, Cloudflare R2, DigitalOcean Spaces, MinIO and others. Let us know if you need a different provider.

Get attachments

The endpoint reference for synced attachments.

Reading applicants

Read candidates, applications and their files for AI screening.