Skip to main content
Recruiting data describes a process rather than a fixed state. The distinction that catches people out is a person versus their attempt at one particular job - status belongs to the attempt, never to the person.

​
The models

Coverage thins toward the bottom of that list, activity history most of all.
Status lives on the application, not the candidate. There is no such thing as a rejected candidate - only a candidate whose application to one job was rejected, who may still be active on another.
is_private marks a candidate restricted inside the customer’s ATS, and can_email records whether they can be contacted. Neither is enforced by the API, so honoring them is your product’s job. Offer status runs DRAFT, APPROVAL-SENT, APPROVED, SENT, SENT-MANUALLY, OPENED, DENIED, SIGNED and DEPRECATED. SENT does not mean accepted and SIGNED does not mean started - only start_date says when someone begins. Stage names are the customer’s own words, so order by stage_order and treat the name as display text.

​
How they connect

Almost everything attaches to the application, not the candidate. Offers, interviews and stages all belong to one attempt at one job, which is what lets the same person be rejected for one role while still active on another. EEOC is the exception. It attaches to the candidate, because demographic data is a fact about a person rather than about an application. A scorecard points at the interview it came from, not just the application, so joining on application alone collapses several rounds into one.

​
How many per candidate

A candidate who applies to three roles is one candidate and three applications, so counting applications to report pipeline headcount overcounts anyone who applied more than once. Some platforms also create a second candidate record rather than a second application on a re-application - see Record identity.

​
What you can write

ATS is the write-heavy category. Sixteen of the eighteen models accept writes, including candidates, applications, jobs, offers, scorecards and scheduled interviews - see Check write support for the schema a given integration expects.

​
EEOC is separated on purpose

EEOC is a separate model because the data is sensitive, tightly restricted in how it can be used, and in most places must not influence hiring decisions. Keeping it apart makes leaving it out a single decision rather than a field-by-field argument.
Most applications should leave EEOC out of scope. Holding demographic data you have no use for adds to your compliance work, your breach risk and what you answer for in a security review.
To exclude it, go to Configure → Scoping and leave the EEOC model unselected - see Scoping. A model outside scope is never synced, so it is decided once rather than per customer. Scope applies going forward only, so resync the connector after excluding it. Where values still appear on the candidate record, some platforms carry demographic fields on their own candidate object and those pass through in raw_data. Where a product needs demographic reporting, read it only through the EEOC model, hold it with its own access controls, and confirm a lawful basis with each customer.