Teamtailor API: clean JSON:API, one key per tenant - and the fix

Teamtailor is a modern ATS with a strong European footprint, and its API is genuinely pleasant - a clean, JSON:API-compliant REST surface. So the friction in Teamtailor API is not the API design. It is that you need one key per tenant.

The Teamtailor API surfaces

• The REST API - api.teamtailor.com/v1/ covering jobs, candidates, applications, departments, and locations. Authentication is Authorization: Token token=<key> with an X-Api-Version header, and responses follow the JSON:APItype/id/attributes envelope.
• The careers site and embed - the public-facing job pages Teamtailor renders for each customer.

Clean, but one key per tenant

Every endpoint is scoped to a single customer’s key, and there is no path to an aggregator-tier credential and no way to enumerate Teamtailor tenants. The API is easy once you have a key; getting a key for every company you care about is the whole problem.

Every Teamtailor tenant through one jobs API

JobsPipe indexes public Teamtailor postings and flattens the JSON:API envelopes into one normalized jobs API, the same shape as 30+ other sources:

curl https://api.jobspipe.dev/v1/jobs/search \
  -H "Authorization: Bearer jp_live_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{ "source_or": ["teamtailor"], "job_title_or": ["frontend engineer"], "job_country_code_or": ["SE", "GB"] }'

One key, every tenant. Scope to one company with company_name_partial_match_or. Details on our Teamtailor source page, and the full comparison in the best jobs APIs of 2026.