Submitting applications

Prepare a candidate’s answers, submit them with a submission token, and track the application until it settles.

Overview

Submitting works the same in both flows. You need an application form and the submission token that came with it, either from a posting inquiry or from your stored application forms. You send the candidate’s answers with that token, and Kombo submits the application on the career site in the background.

How it works

Preparing the answers

Answers are validated against the exact form the token was issued with, so most rejected submissions trace back to how the answers were collected. The Application form page covers each rule in detail:

• Answer format. Each question type expects a specific answer shape, for example option IDs for selects and a base64 object for files. See Question type details.
• Conditional questions. Answer a question only while its display_when condition is met, and remove an answer once its condition stops being met. A required question is required only while visible. See Conditional rendering.
• Storing answers. Keep one map of question_id to answer per candidate, and use it both for evaluating conditions and for building the submission. Omit unanswered optional questions. See Storing candidate answers.
• Pre-filled answers. Questions you pre-fill from unified keys are submitted like any other answer, by question_id. A required question you hide because it was pre-filled still needs its answer in the submission.

Sending the application

POST Apply takes the submission token and the answers:

{
  "submission_token": "<token>",
  "candidate_email": "[e-mail]",
  "screening_question_answers": [
    {
      "question_id": "6VrjehyBk685vubNydiR1hSn",
      "answer": "John"
    }
  ]
}

Field	Required	Behavior
submission_token	Yes	The token that came with the form you answered.
candidate_email	Yes	Supply this from your own system. Do not ask for it on the form. It does not prevent duplicate applications.
screening_question_answers	Yes	One entry per answered question, as described in Preparing the answers.
query_params	No	Appended to the job posting URL when applying. See Query parameters.
additional_clicks	No	Simulates the job being opened this many extra times, scattered over 60 minutes by default.

A question ID that is not in the form, or a missing required answer, fails the request rather than being ignored.

Tracking the application

Applying is asynchronous. The response confirms that Kombo accepted the application and queued it:

{
  "id": "ADbmw5XSkeCSE1fAucoxEGnwZ",
  "posting_id": "JDn252PEYa4rMhKbJBjtn3ng",
  "status": "PENDING",
  "created_at": "2025-01-01T00:00:00.000Z",
  "updated_at": "2025-03-02T23:12:32.000Z"
}

Keep the returned id. It is how you match this application to webhooks later on.

Status	Meaning
PENDING	We are applying, or the application is waiting on manual review.
SUBMITTED	The application reached the job site.
DUPLICATE	The ATS rejected it because this candidate had already applied.
FAILED	We established that the application cannot be submitted.

We emit the application status updated webhook on every status except PENDING, so one arrives per application once it settles. GET Applications is the polling alternative, and carries the same updated_after filter as the posting endpoints.

proxy_email is only populated once an application is SUBMITTED. See Candidate account creation to learn when we create an account on the candidate’s behalf.

A failure does not reach you immediately. Every failed submission goes through Kombo’s QA first, and we only report FAILED once we have confirmed we cannot submit the application in any way. See QA mode for more info.

API reference

• POST Apply
• GET Applications