Getting started with the ATS API
This guide outlines the setup steps required before you can create jobs or applications via the ATS API.
Missing reference data causes most integration failures. Teams, locations, and employment types must exist in your organization and you need their IDs before making POST requests.
Prerequisites
- A Deel account with ATS enabled
- An API token with
ats:readandats:writescopes. See Authentication for setup instructions. - The
organizations:writescope if you need to create teams (see below).
About team IDs
Jobs require at least one team_id. Define your teams in the Deel App under Organization settings -> Organization -> Groups, or via POST /hris/organization_structures by including a teams array in the request body:
Once created, those teams appear immediately in GET /teams. Retrieve their UUIDs to use in ATS calls:
If teams already exist in your organization, skip the creation step and go straight to GET /teams.
Step 1: Verify authentication
Confirm your token has the correct scopes by calling a lightweight read endpoint.
A 200 response confirms authentication is working. A 401 means your token is missing or invalid. A 403 means your token lacks the ats:read scope.
Step 2: Retrieve locations
Jobs require at least one location. Fetch all available locations and store the IDs you will use.
Store the id values for locations you will assign to jobs.
Step 3: Retrieve employment types
Both job creation and application creation require an employment type.
Step 4: Retrieve your hiring member ID
Some operations, such as advancing an application through an interview plan stage, require a creator_id. This is your HRIS organization user ID.
Store the hris_organization_user_id. You will use it as creator_id when associating applications with interview plan stages.
Step 5: Retrieve departments (optional)
Departments are optional on jobs but useful for filtering and reporting.
Pagination
All list endpoints use cursor-based pagination. Use the next_cursor value from a response as the cursor query parameter in the next request.
Check has_more in each response to determine whether additional pages exist.
Fetch and cache reference data (locations, employment types, departments) at integration startup rather than on every request. These values change infrequently.