Migrate your Teamtailor data

Candidates are the primary object in Teamtailor. The API supports full CRUD and filtering by department, location, and custom properties. We export all standard candidate fields plus any custom fields configured on the candidate card. Candidate activity history and application stages are preserved as part of the export.

Jobs expose title, status, department, location, and body content. The API returns jobs with their public URL and internal metadata. We map job status (active/paused/closed) and preserve the job description HTML as written in the editor.

Applications link a Candidate to a Job with a status, source, and timestamps. The API supports filtering by job or candidate. We export the full application timeline including rejection reasons if present. Note that application answers (responses to job-specific questions) are stored in a separate endpoint and require an additional batch request.

Custom fields for candidates are user-defined key-value pairs visible in the candidate card. Their field names and types vary per-customer, so we discover the schema during scoping and map each field explicitly. Free-text, dropdown, and date fields are handled distinctly at write time in the destination.

Custom fields on job postings differ from candidate custom fields and are scoped to the job object. These fields are optional and their presence depends on how the customer configured their job templates. We export them as-is and map them to equivalent destination job fields where supported.

Departments are a taxonomy object used to categorize jobs and sometimes candidates. The API exposes them as a lightweight relation. We import them as a flat list and map them to the destination department or team object.

Locations function similarly to departments — they tag jobs and sometimes candidates with a geographic dimension. We export locations as a list and map them to the destination location or office object.

Users represent hiring managers and recruiters with roles in the platform. The API supports creating, listing, and deleting users. We export the user list to map owner assignments on candidates and jobs during migration. Users can be assigned as hiring managers or collaborators.

Interview Kits group questions used for structured candidate evaluation. The questions endpoint is queryable via API. These are tied to jobs rather than candidates, so during migration we map kit names to the destination evaluation template. Not all ATS platforms have an equivalent Interview Kit concept, which may require a custom field workaround.

Candidate resumes, cover letters, and other files are stored as upload objects referenced on the application. The API provides a URL to the uploaded file but the file itself must be fetched separately. We export the file URL and re-upload to the destination system, preserving the original filename. Large file handling depends on the destination platform's attachment limits.

Automation rules and triggers (e.g., send email when candidate moves to stage 2) are configuration data stored in Teamtailor and are not exposed via the public API in a structured way. We do not migrate automation logic; instead, we document the active automations during scoping so customers can manually recreate them in the destination platform.

Teamtailor's Multi-Brand feature allows a single account to host multiple employer brands with separate career sites and sometimes separate candidate pools. We handle this by scoping the export to the primary entity unless a multi-entity migration is explicitly requested. Entity-specific job and candidate isolation must be mapped per entity during import.