Skip to main content

​
Overview

GET Job Postings Forms returns all job postings, each with its application form and submission token. Once you have a candidate’s answers, include the submission token in the application request so we know which job posting the application is for. This flow relies on you to keep your database in sync by polling this endpoint regularly. Whenever our parsing updates a job posting or its form, you need to fetch again to pick up the change.
Use this flow if you need to store the application form in your product (e.g. if you are a service distributing the form to other job boards). If you are a job board yourself, use our inquiry flow for a better candidate experience.We generally do not recommend this flow unless you have a hard requirement to cache the data. Job postings change over time. With the inquiry flow, you always get the newest version of the application form. Owning the sync yourself can quickly become a complex infrastructure-heavy operation.

​
How it works

​
Fetching the forms

Each response carries a page of postings and a next cursor. Page until next is null.
Pages hold at most five postings, because every applyable one on the page carries a full application form. An initial sync of a large catalogue therefore takes many requests. Later syncs are small, as long as you filter them.
The endpoint accepts the following query parameter filters: career_site_ids and job_codes to narrow the catalogue, and updated_after to fetch only what changed. Data fetching describes how to keep your copy current with updated_after and the data-changed webhook.

​
Posting availability

Job posting results include applyable and non-applyable postings. Only jobs with the APPLYABLE availability include the application_form and submission_token. In every other state, both properties are null. The availability property tells you why: Clear the form you are storing when a posting stops being APPLYABLE, rather than keeping it around in case the job comes back. If it does, the next sync hands you a fresh one.

​
Submission token mechanics

Every applyable posting includes a unique submission_token. Unlike the short-lived single-use tokens from an inquiry, these are meant to be stored:
  • They do not expire. A token stays valid for as long as the form it came with is current.
  • They are reusable. Every accepted submission creates its own application, so one token serves every candidate who applies to that job.
  • They belong to one form. Store the token and the form together and replace them together. A token paired with the wrong form is rejected.
Do not hold a token longer than the form it arrived with. When a sync returns a posting with a new form, the pair you stored is out of date, and an application submitted with it could fail against the live job site.

​
Submitting the application

When a candidate has answered a stored form, submit the answers with the token you stored alongside it. See Submitting applications for preparing the answers, the request, and tracking the result.

​
API reference