Recruitee API explained: what it covers, where it gets tricky, and how 100Hires compares

Building against the Recruitee API is not hard. Figuring out which of its three API surfaces and two documentation sites you should be reading is the hard part.

This guide maps what the Recruitee (now Tellent Recruitee) API includes, what its documentation covers and skips, and how it stacks up against the 100Hires REST API.

Claims about Recruitee's API below trace to its live documentation or to linked public posts. Our own product claims trace to the 100Hires OpenAPI spec.

It is written for the founder or ops person wiring their recruiting software into a CRM, Slack, or a reporting sheet, and for developers sizing up the work before they commit to it.

Key takeaways

• Three separate surfaces: Recruitee splits its API into a main ATS API, an unauthenticated Careers Site API, and an OAuth Marketplace API for approved partners. Each has its own base URL and auth model
• Two documentation sites: a curated reference covers a narrow slice of endpoints; the "full documentation" portal mixes recruiting endpoints with Recruitee's own admin and billing internals, with no version stamps
• A legacy jobs endpoint: as of this writing, the primary jobs list endpoint carries a "Legacy endpoint" banner and documents no pagination parameters
• Seven webhook events: candidate and job events are covered; evaluations, interviews, notes, and messages are not
• The 100Hires contrast: one OpenAPI 3.1 spec with 89 paths and 133 operations, rate limits documented in the spec, uniform pagination, and webhook secret rotation

What does the Recruitee API actually include?

Recruitee provides developers with three distinct APIs. Knowing which one you need helps you avoid a common false start.

The main ATS API uses a personal token you generate under Settings, then Apps and plugins. Per Recruitee's API FAQ, the token inherits the permissions of whoever created it - there are no separate API scopes.

The documented rate limit is 1,000 requests per minute per token, and every call carries your company ID in the path. Coverage centers on candidates, offers, search, departments, locations, and custom fields.

One terminology quirk to absorb early: the API calls jobs "offers." The same offer object covers both job postings and talent pools, disambiguated by a kind parameter. Filter by kind when you query jobs, or the response includes talent pools too.

For the common cases, the main API does its job. Public tutorials and small community projects show developers pulling candidate and job data and building simple exports on top of it.

The Careers Site API is a separate, unauthenticated surface on your careers subdomain. It shows published jobs and accepts applications - useful for a custom careers page, read-only beyond that. Its own docs page says the documentation is still a work in progress.

The third surface is for vendors. The Marketplace partner flow requires registering a codename, providing four webhook URLs, and obtaining Recruitee's approval.

Per Recruitee's FAQ, broader endpoint access still depends on each end customer generating a personal token and handing it over to the vendor.

There is a low-code path too. The API FAQ documents three feed formats on the careers subdomain - formatted XML, raw XML, and JSON. The provided XML feeds are not customizable; a custom feed means building it yourself via the API.

That is the map. Here is what it does not show.

Where the Recruitee API gets tricky

Much of what follows reflects fixable gaps in the documentation rather than a product failure, but you should know about them before you commit.

Two documentation sites, and no changelog

The curated reference at docs.recruitee.com indexes roughly a dozen endpoint pages. The "full documentation" link from its getting-started guide lands on apidocs.recruitee.com - a very different animal.

That second site is a static reference with 51 namespaces, where recruiting endpoints sit next to Recruitee's own admin, billing, and GDPR internals. It carries no version or date stamps.

The word "deprecated" appears 155 times in its source, and nothing marks which endpoints are stable for external use.

There is no API changelog either - docs.recruitee.com/changelog returns a 404. Information about API changes appears in support-center articles, not in the reference itself.

Developers feel this. Back in 2020, one engineer publicly asked Recruitee to add a JSON schema to the API docs, tired of guessing response types. As of this writing, we could find no published machine-readable schema for the public API.

To be fair: several curated reference pages do carry update timestamps, and Recruitee maintains a public status page. Recruitee has some elements of good developer communication - they just do not extend to the API reference itself.

The curated reference covers a narrow slice

Here is what the curated reference documents: creating and searching candidates, creating, reading, and updating offers, reading departments and locations, setting custom field values, and the careers-site apply flow. That is the dependable core.

What you will not find there: reference pages for notes, interviews, or evaluations (those URLs return 404s), and the site's own index lists no pages for single-candidate GET, candidate update or delete, or messages.

Operations like updating a candidate or creating a note do exist - they appear in the full reference at apidocs.recruitee.com. The catch is that you are building against pages with no stability guidance, no dates, and heavy deprecation markers, judging for yourself what is safe.

A concrete consequence: say you want a Slack notification when someone submits a scorecard. There is no evaluation webhook event, and no curated read endpoint to poll for evaluations either. There is no documented way to build that workflow.

This matches what reviewers have said for years. When we synthesized about 175 public G2 and Capterra reviews of Recruitee posted between 2022 and 2024, requests for deeper integrations came up 12 times, and easier ways to get data out came up 3 times.

A legacy jobs endpoint and pagination guesswork

The jobs list endpoint, GET /offers, carries a "Legacy endpoint" banner as of this writing - and documents zero pagination parameters. No page, no limit, no cursor.

The banner points to a support article announcing a rebuild with a December 1, 2025 deadline. That article does not document the new parameter set either. If you integrate today, you test pagination behavior yourself.

Candidate search, by contrast, has clear page and limit parameters, with a documented ceiling of 10,000 candidates per call. So pagination works differently across endpoints, and the primary jobs resource is the underdocumented one.

The rate-limit documentation followed a similar pattern: the same support article set an October 15, 2025 rollout for formal request limits without stating the numbers. The 1,000 per minute figure lives on a different page, the getting-started guide.

Webhooks cover seven events

Recruitee's webhooks fire on seven event types: candidate created, assigned, moved (which bundles disqualified and requalified), and deleted, plus job published, unpublished, and updated.

Notice what is missing: no evaluation submitted, no interview scheduled, no note created, no message activity. So reacting to submitted feedback has no documented route - neither a webhook event nor a curated endpoint to poll.

One practitioner asked publicly whether a stage-triggered assessment flow was possible through the API or hooks - the kind of question that comes up when docs leave capability unclear.

Recruitee's own FAQ states that assessments can only be sent manually, with no timeline for automation.

The delivery mechanics, though, are solid and well documented in the same webhooks guide. Nine retries with escalating backoff from 1 minute to 48 hours, a 10-second timeout, HMAC-SHA256 signatures, and 30-day delivery logs.

The caveats: webhook management lives in the app UI - the curated reference documents no endpoints for creating or listing webhooks - and no secret rotation flow is documented.

Per the same guide, deliveries are rate-limited too, to 5 per minute during a trial and 100 per minute on paid plans, with over-limit deliveries delayed by roughly 10 minutes.

Tokens, access, and support boundaries

Personal tokens never expire and cannot be regenerated - replacing one means creating a new token and swapping it in. Per the getting-started guide, not even an account administrator can view a user's tokens.

Two details for your security review: token creation can be limited through the Manage API tokens permission in hiring roles, and Recruitee's audit logs track changes only - they are explicitly not designed to track data access.

Support has explicit boundaries. The API support article states that Recruitee will point you to endpoints and share example calls, but will not design your integration or review your code - and that more comprehensive support is reserved for its Optimize plan.

What does hands-on work feel like? A Postman walkthrough of the API shows requests built by hand, filters passed as a raw JSON blob in a query parameter, and date filters that want epoch millisecond timestamps - the presenter stops to convert dates in a browser console.

We found no official SDK to smooth this over. A GitHub search turns up only small community projects, none with more than a dozen stars.

How does the 100Hires API compare?

The 100Hires API takes the opposite approach to documentation: everything lives in one machine-readable OpenAPI 3.1 spec at api.100hires.com/v2/openapi.json - 89 paths and 133 operations at the time of writing.

The table below compares what each vendor's documentation makes discoverable and dependable. Where a Recruitee operation exists only in the full reference at apidocs.recruitee.com, the row says so. Sources for every row are linked in the sections above.

In practice, the single spec changes the workflow. You generate a key in Settings, then Integrations, point Postman, Cursor, or an LLM agent at the spec URL, and the entire API becomes discoverable - every endpoint with parameters, examples, and error formats.

The spec gets small details right too. Path parameters for candidates and jobs accept either human-readable aliases or numeric IDs, and common workflows are written out as numbered endpoint sequences in the spec description.

Applications are a first-class resource, with operations to advance, reject, unreject, hire, and transfer, plus stage history and AI score fields available for each application. Batch endpoints let you move or reject multiple candidates in a single call.

That API coverage supports practical projects: two-way candidate synchronization with a CRM, evaluation results sent to a BI dashboard, or an agent that reads AI scores and advances candidates above a threshold.

Webhooks are REST resources you create per job or company, and their HMAC-SHA256 secrets can be rotated under a dual-signature grace window - zero downtime.

The comparison cuts both ways - here is where Recruitee is ahead. Its documented throughput ceiling is far higher: 1,000 requests per minute versus the 100 requests per 10 minutes hard limit on new 100Hires keys, which stays until you ask support to lift it.

Recruitee documents an explicit nine-step webhook retry schedule; the 100Hires spec gives qualitative retry guidance. Recruitee documents seven webhook event types across candidates and jobs.

Recruitee runs an OAuth partner program for marketplace vendors; the 100Hires spec documents a single bearer-key model with no partner OAuth flow. And 100Hires keys stay disabled until your company passes verification.

Which one should you build on?

If your team already runs Recruitee and you need candidate intake, job feeds on your website, or new-applicant notifications, the Recruitee API handles those today.

Budget extra time for reading two documentation sites, and confirm pagination behavior on the jobs endpoint in a test run before production.

If you need to connect many record types across several systems, middleware works too: Apideck, Knit, and Bindbee all maintain Recruitee connectors with varying coverage. In return for a subscription fee, the provider interprets the documentation for you.

And if you are still choosing an ATS and integrations are a primary requirement, evaluate the API the way you would the product: read the spec before you buy.

The 100Hires spec is public, and the API is free on all plans with self-serve keys (see 100Hires pricing).

And the resources that matter for automation - applications, evaluations, notes, messages - are documented endpoints.

Prefer no-code? The 100Hires Zapier integration covers the basics, with documented triggers such as "new candidate" and actions such as "move candidate to stage."

A practical next step: pull up the 100Hires OpenAPI spec and the Recruitee docs side by side for your three most important workflows. If you would like a guided walkthrough of the 100Hires API against your use case, book a demo.

Frequently asked questions

Does Recruitee have a public API?

Yes. Recruitee offers a main ATS API (bearer token), an unauthenticated Careers Site API, and an OAuth Marketplace API for approved partners. 100Hires takes a simpler route: one OpenAPI spec that OpenAPI-compatible tools can read at api.100hires.com/v2/openapi.json.

Does the Recruitee API have webhooks?

Yes. Its webhooks guide documents seven event types: candidate created, assigned, moved, and deleted, plus job published, unpublished, and updated. No events cover evaluations or interviews. 100Hires treats webhooks as REST resources with API-driven creation and secret rotation.

What are the Recruitee API rate limits?

Recruitee's getting-started guide states 1,000 requests per minute per token, with no documented 429 header contract. 100Hires documents limits inside its OpenAPI spec, including X-RateLimit headers: new keys get 100 requests per 10 minutes until support lifts the cap.

Where is the Recruitee API documentation?

In three places: the curated reference at docs.recruitee.com, the full reference at apidocs.recruitee.com, and support-center articles. There is no changelog page. 100Hires keeps its whole reference at one canonical spec URL.

Can I export my data from Recruitee via the API?

Partially. Its reference page allows up to 10,000 records per candidate search call, and job feeds come as XML or JSON. Candidate update and delete appear only in the full reference. The 100Hires API documents full candidate CRUD, with resume files and activity timelines.

Want to see what a fully documented ATS API feels like in practice? Start a 100Hires trial and generate your API key under Settings, then Integrations.