TL;DR

A REST API (Representational State Transfer Application Programming Interface) is an architectural style for building web services that communicate over HTTP using standard methods like GET, POST, PUT, and DELETE. In recruitment, REST APIs are the primary mechanism by which ATS platforms, job boards, background check providers, and other tools exchange data. If two recruitment tools are integrated, a REST API is almost certainly how they talk.

How REST APIs Work

REST is not a protocol - it's a set of constraints on how to design an API over HTTP. The key idea is that every resource (a job posting, a candidate record, an interview event) has a stable URL address, and you interact with that resource by sending HTTP verbs to that address. GET /candidates/12345 retrieves a candidate. PUT /candidates/12345 updates them. DELETE /candidates/12345 removes them. POST /candidates creates a new one. This uniformity means that any developer who understands HTTP can use any REST API with minimal learning curve.

Requests and responses are typically formatted as JSON - a lightweight, human-readable data format that every programming language handles natively. When Bullhorn's API returns a candidate record, it sends back a JSON object containing the candidate's name, contact information, work history, and any custom fields configured by the tenant. The consuming application parses that JSON and does whatever it needs to with the data: display it, store it, transform it, or pass it along to another system.

Authentication is a separate layer on top of the REST architecture. Most modern recruitment APIs authenticate via OAuth 2.0 bearer tokens - the client sends an Authorization: Bearer <token> header with every request. API keys are also common, particularly for server-to-server integrations that don't involve user logins. Greenhouse, Lever, and Bullhorn all use OAuth for user-facing integrations and API keys for background service accounts.

Pagination is an important practical detail that affects how integrations perform. ATS databases can hold millions of candidate records. An API call for "all candidates" without pagination would time out and transfer gigabytes of data. REST APIs handle this by returning a page of results (typically 25-100 records) along with a link or cursor for the next page. An integration that needs to sync the full candidate database must implement pagination logic to walk through all pages sequentially or in parallel.

Why It Matters in Recruitment

The modern recruitment tech stack is not a single product - it's 5 to 20 products that need to stay in sync. A job opening created in the ATS needs to flow to the job board, the careers page, the sourcing tool, and the analytics dashboard. A candidate who completes a background check in one system needs that result reflected in the ATS. REST APIs are the connective tissue that makes this possible without manual data entry or CSV imports.

The quality of a vendor's REST API is a direct indicator of how well that product will integrate with the rest of the stack. APIs with consistent URL structures, comprehensive documentation, predictable error responses, and sensible rate limits are dramatically easier to build on than APIs that are inconsistently designed or poorly documented. When evaluating recruitment technology, asking to see the API documentation before signing a contract is legitimate due diligence - not a technical detail to defer.

Rate limits matter operationally. Greenhouse's Harvest API allows around 50 requests per 10 seconds per API key. Bullhorn's limits vary by subscription tier. An integration that triggers a high-volume sync - importing 50,000 candidate records, for example - needs to account for these limits in its design, or it will hit a 429 Too Many Requests error halfway through and leave the systems in an inconsistent state.

REST API in Practice

A [staffing agency](/glossary/staffing-agency)'s operations team wants to build a weekly report that shows new placements across all their clients. They use Bullhorn as their ATS, which exposes a REST API at https://rest.bullhornstaffing.com/rest-services/. The developer authenticates with OAuth, then calls GET /entity/Placement?fields=id,dateAdded,client,candidate,salary&where=dateAdded>=[last week]. Bullhorn returns a paginated JSON array of placement records. The developer iterates through all pages, aggregates the data, and writes it to a reporting database.

The same REST API is used by every integration in the agency's stack - the payroll system pulling placement data to generate invoices, the compliance tool checking that all required documents are attached before a placement is finalized, and the analytics platform building pipeline dashboards. Each integration authenticates separately and accesses only the data its OAuth scope permits.

Key Considerations