Retrieve a list of ATS applications
Use this endpoint to track where candidates sit in the hiring pipeline and to surface stalled applications that need follow-up — for instance those that entered their current stage long ago and have not advanced. The full stage-transition history can be requested per item when the current stage alone is not enough.
Token scopes: ats:read, worker:read
Authentication
Authentication
The Deel API uses bearer tokens to authenticate requests. All API calls must be made over HTTPS — calls over plain HTTP or without authentication will fail.
curl -X GET 'https://api.deel.training/rest/v2/contracts' \
-H 'Authorization: Bearer YOUR-TOKEN-HERE'
Standard OAuth2 security scheme based on https://swagger.io/docs/specification/authentication/
Query parameters
Return applications to any of these jobs (up to 100). Combined with job_id as one set. Jobs the caller cannot access are left out silently rather than rejected.
Return applications to jobs on whose hiring team one of these HRIS organization users sits (up to 100) — a person’s pipeline. Always intersected with the jobs the caller can access.
Narrow hiring_member_hou_ids to jobs where those people hold one of these roles (up to 100), using the role_id values returned by the hiring members list. Requires hiring_member_hou_ids. Only organizations that use roles and permissions have per-job roles; others get a 400.
Filter by the CURRENT interview plan stage IDs (comma-separated). Applications that have since moved to another stage are excluded — use reached_interview_plan_stage_ids for those.
Filter by interview plan stage IDs the application has EVER been in (comma-separated), including applications that have since advanced, been hired or been archived.
Return only applications that moved to their current stage strictly before this ISO 8601 datetime (stalled candidates)
Filter by archivation reason IDs (comma-separated); see GET /rest/ats/reasons with reason_group_slug=CANDIDATE_ARCHIVATION
How candidate_tag_ids are combined: ANY (default) matches candidates with at least one of the tags, ALL requires every tag
Optional expansions to embed on each item. STAGE_HISTORY adds the full stage timeline with entered/exited timestamps.
Filter by candidate tag IDs (comma-separated)
Filter by application source (comma-separated)
Filter applications by current stage category type slugs. Accepted values are lead, active and completed, in either case — the job list reports them uppercase and this filter accepts that form too.
Filter applications by current stage default type slugs (e.g. new_lead, application_review, offer, hired, archived), in either case. Use ‘others’ for custom stages.
Filter applications updated after this timestamp (ISO 8601 format)
Response
Cursor to fetch the next page; null when there are no more pages