> ## 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.

# 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](/ai-apply/job-boards/posting-inquiry) or from your [stored application forms](/ai-apply/job-distributors/storing-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

```mermaid theme={null}
sequenceDiagram
    participant You
    participant Kombo
    You->>You: Collect answers to the form
    You->>Kombo: POST apply (token + answers)
    Kombo-->>You: Application id, status PENDING
    Kombo->>Kombo: Submit on the career site
    Kombo->>You: Application status updated webhook
```

## 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](/ai-apply/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](/ai-apply/application-form#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](/ai-apply/application-form#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](/ai-apply/application-form#storing-candidate-answers).
* **Pre-filled answers.** Questions you pre-fill from [unified keys](/ai-apply/unified-keys#pre-filling-questions-in-your-ui) 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](/ai-apply/v1/post-apply) takes the submission token and the answers:

```json theme={null}
{
  "submission_token": "<token>",
  "candidate_email": "john.doe@gmail.com",
  "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](#preparing-the-answers).                                   |
| `query_params`               | No       | Appended to the job posting URL when applying. See [Query parameters](/ai-apply/query-parameters#query-parameters-in-applications). |
| `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:

```json theme={null}
{
  "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](/ai-apply/job-boards/webhooks#application-updated-webhook) on every status except `PENDING`, so one arrives per application once it settles. [GET Applications](/ai-apply/v1/get-applications) is the polling alternative, and carries the same `updated_after` filter as the posting endpoints.

<Note>
  `proxy_email` is only populated once an application is `SUBMITTED`. See
  [Candidate account creation](/ai-apply/candidate-account-creation) to learn
  when we create an account on the candidate's behalf.
</Note>

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](/ai-apply/qa-mode) for more info.

## API reference

* [POST Apply](/ai-apply/v1/post-apply)
* [GET Applications](/ai-apply/v1/get-applications)