REST API or GraphQL: What Matters in an ATS Integration

You have been asked to connect an applicant tracking system (ATS) to two job boards. At the kickoff, someone asks whether you will build it "the modern way with GraphQL" or "the classic way with REST". Two weeks later the picture is clear: the ATS delivers jobs through a REST interface with its own auth scheme, the job board expects a different field format, and nobody on your team ever decided on the API style. It was fixed before the project began.

This article is for tech leads and developers who have to connect recruiting systems to each other. It explains when the choice is yours at all, what independent studies on GraphQL performance measure (as opposed to what marketing blogs make of them), and where over-fetching, versioning and rate limiting create real work. The short answer up front: the style is rarely the problem. The questions that cost time are about authentication methods, field semantics, and who notices a change to someone else's API before it goes live.

• REST remains the default: in Postman's survey, 93% of respondents use REST and 33% use GraphQL. In practice, one does not exclude the other (Postman, State of the API 2025).
• In a controlled test with two Go microservices, REST responded more than three times faster on average (≈250 ms versus ≈850 ms), while REST transferred close to 4 GB of data in total and GraphQL only a few hundred MB (Elghazal, Aneiba & Shahra, WEBIST 2025).
• For data-intensive database operations, a master's thesis from the University of Washington Tacoma measured 25–67% lower response times for a self-hosted Apollo GraphQL server than for REST on most operations, with weaker scaling under very high load (Jin, UW Tacoma ResearchWorks, 2025).
• At the largest workload tested, 3,000 requests, GraphQL fell behind REST in another study. At small loads of 100 requests, the two barely differed (Seabra, Nazário & Pinto, SBCARS 2019).
• Only 26% of teams use semantic versioning for their APIs, although 60% version them at all (Postman, State of the API 2025). This is where the real integration risk lies, whatever the style.
• Nearly 69% of the 160 publicly reachable GraphQL endpoints that Escape scanned in 2024 had issues related to unrestricted resource consumption, which makes them susceptible to denial-of-service attacks (Escape, State of GraphQL Security 2024).

Who decides the API style in an inbound ATS integration?

The vendor of the system you are connecting to. Not you. In an inbound integration you consume someone else's interface in the form it already has. A REST-based applicant tracking system does not become GraphQL because your team votes for it. You only get to choose the style of the API you publish yourself.

That sounds trivial, but it is the most common misconception in integration projects. "REST versus GraphQL" is a design debate for your own APIs. Once you connect external systems, it turns into a translation job: you work with what exists, and you still have to present a consistent interface to the outside world.

This distinction is why a managed connectivity layer between the ATS and your channels saves many teams more effort than any decision about style. The variety of connected systems does not go away, but someone else does the translation work.

Which API styles do you run into in a recruiting tech stack?

Mostly REST with JSON, plus REST variants with conventions of their own. Two examples serve as a reference throughout this article. SAP SuccessFactors delivers its talent management data through OData V2 APIs (ServiceNow documentation on the SuccessFactors integration, 2026), which is REST with its own query syntax for filtering, expansion and pagination. Teamtailor follows the JSON:API specification, a stricter REST convention for relationships and embedded resources, and authenticates access with an API key generated in the account settings (Teamtailor Support Center, 2026).

Neither system offers GraphQL. In Postman's survey, 33% of respondents use GraphQL (Postman, State of the API 2025), but the report does not break that figure down by type of system. When you connect an ATS or an HR system, you are in practice almost always consuming a REST-style interface. There are special cases such as OData or JSON:API, but no GraphQL.

This variety is not a transitional phase that will sort itself out in two years. Many of these systems have been in use at large enterprises for more than a decade, in configurations that have grown over the years, and nobody rebuilds them because an integration partner would like it. If you connect several of these systems at once, a large share of the project time goes into authentication methods, pagination and field semantics, and little of it into the API style. Those topics are the core of an ATS integration, whether the documentation ends up saying REST, OData or JSON:API.

What do the performance studies show, and what do they not show?

There is no single picture. What you see depends heavily on the scenario. Three independent measurements reach different and partly contradictory results, because they test different things.

The University of Washington Tacoma thesis shows GraphQL ahead when it bundles several steps of a workflow into a single call, and on complex database queries with multiple joins. It explicitly does not hold under very high concurrency, where GraphQL scaled less well than REST (Jin, UW Tacoma ResearchWorks, 2025). Elghazal, Aneiba and Shahra get a different result in their head-to-head comparison: in their setup REST was well ahead in response time, while GraphQL transferred far less data (Elghazal, Aneiba & Shahra, WEBIST 2025). Seabra, Nazário and Pinto observed a third variant in three apps they built and migrated themselves. GraphQL improved requests per second and transfer rate in two of the three, performed about the same as REST at 100 requests, and fell behind at 3,000 requests (Seabra, Nazário & Pinto, SBCARS 2019).

What they have in common: none of the three studies supports the blanket claim "GraphQL is faster", or its opposite. They agree on one practical point: under high load, REST held up better than GraphQL. The GraphQL advantages that Jin and Seabra et al. measured appeared below the highest loads they tested, and Elghazal et al. found REST faster on average. For server-to-server synchronization between an ATS and a job board that runs in nightly batches, the high-load finding is the one that matters.

Why the three studies disagree is telling in itself. They differ in their results, and they also differ in what they measured in the first place. Jin tests a serverless setup with one large public dataset and nine database endpoints, and varies the number of concurrent clients. Elghazal, Aneiba and Shahra test two conventional, long-running microservices under a load that ramps up to 1,000 virtual users. Seabra, Nazário and Pinto build three small applications in REST, migrate them to GraphQL and load-test both versions. Quote a single number from one of these studies without naming the setup, and you carry a result over to a scenario the study never tested. That is the mistake marketing comparisons between REST and GraphQL make most often.

What does over-fetching cost in practice, and where does GraphQL not help?

Less than the argument suggests, but it is measurable in data volume. In the WEBIST 2025 measurements, REST transferred far more data than GraphQL, and that does not automatically mean slower responses: REST was faster despite the larger data volume (Elghazal, Aneiba & Shahra, WEBIST 2025). Over-fetching is therefore mainly a bandwidth and mobile-network problem, not a general performance problem.

For server-to-server synchronization between an ATS and a job board, bandwidth is rarely the bottleneck. The bottlenecks are the vendor's rate limits, pagination across tens of thousands of records, and fields that each customer populates differently.

Three of five typical integration problems remain, whatever the API style. That is the key point. The effort a team feels when syncing candidate data back to the ATS rarely comes from the style. It usually comes from field semantics, not from the transport format.

How do versioning and breaking changes differ?

REST usually versions through the path, GraphQL through field deprecation in the schema. Both only work if the vendor is more disciplined than average. In Postman's survey, 60% of teams version their APIs at all, but only 26% use semantic versioning (Postman, State of the API 2025). The real risk is communication, not technology.

On paper, GraphQL's approach has an advantage. A field is marked as deprecated and stays in place, clients migrate at their own pace, and there is no separate /v2 twin. In practice, the schema only ever grows, and rarely does anyone dare to remove old fields.

For you as the integrator, a different question counts: do you hear about a change before it goes live? With ATS vendors, the answer is often no. That is why contract tests against the external API and alerts on schema drift matter more than the choice of style.

Why is rate limiting harder to plan for with GraphQL?

Because a request is no longer a meaningful unit. With REST, one call costs one call, and a limit of 1,000 requests per hour is predictable for both sides. With GraphQL, a single query can load a hundred records with five relationships each. The cost sits in the query body, not in the number of requests.

Vendors handle this with cost models. Every field and every resolved list gets a weight, and the limit applies to the total. Technically that is a clean solution, but client teams find it harder to forecast, because you cannot be sure in advance whether a query fits your budget. Without such a cost model, the usual fallback is a fixed depth limit per query. It restricts simple queries for no good reason and still does not reliably catch complex ones.

If you are planning a sync job that reconciles a hundred thousand job postings overnight, a request limit is the more comfortable basis for capacity planning. The downside is real, though. Publicly reachable GraphQL endpoints without depth and complexity limits are open to expensive queries, and in Escape's 2024 scan nearly 69% of endpoints had issues related to unrestricted resource consumption (Escape, State of GraphQL Security 2024).

Curious how it workswith your stack?

Book a demo

Book a demo

→ Magic-link setup

→ Field mapping included

→ Fast go-live

How does error handling differ in practice?

Not in the way the popular rule of thumb "GraphQL always responds with HTTP 200" suggests. The GraphQL over HTTP specification explicitly allows 4xx and 5xx codes for request errors: 400 when the JSON body or the GraphQL document cannot be parsed, 422 when validation fails. The exception is a query that was executed and whose result holds some data and some errors. For that case the current draft recommends 294, a code defined for "Partial Success", and recommends it only alongside the GraphQL-specific response format application/graphql-response+json. Clients that do not recognize 294 must treat it like 200, and for legacy clients that only accept application/json the draft keeps the status code and swaps the Content-Type (GraphQL over HTTP specification, GraphQL Working Group, Draft 2026).

For an integration, the practical difference is still large. With GraphQL, a response can contain some data and some errors. A frontend can live with that, since it renders whatever is there. For a sync process it is risky: a partial result looks like a success and may pass incomplete data downstream.

In practice this means that with GraphQL you need an explicit rule for when a partial result counts as a failure, and you have to check the errors array as strictly as a status code. REST needs the same discipline, but the starting point is clearer. A 404 means 404, a 429 means retry, a 422 means a data error.

Which API style should you choose for your own interface?

Go by how your clients use the API, not by what is newest. If you serve many unknown clients with different data needs and deep relationships, that points to GraphQL. The UW Tacoma thesis measured its largest advantages at medium concurrency, including on a complex query with multiple joins. If your traffic is machine-to-machine synchronization, webhooks and batch jobs, REST is the more predictable foundation, and 93% of respondents in Postman's survey already use it (Postman, State of the API 2025).

Our honest advice: pick the style your team can operate for years. For integration partners, a well-documented, versioned REST API with webhooks is usually worth more than a GraphQL endpoint with no complexity limits and no changelog. That goes double for small teams. The caching and rate-limiting layer that REST gets for free through HTTP is something you have to build yourself with GraphQL, and then keep running.

If it turns out that the real effort lies in several different interfaces with several authentication methods, and the API style has little to do with it, talk to us. No pitch, just a look at your list of systems.