Should AI agents use a unified API or native APIs?
July 17, 2026
Unified APIs break for AI agents in three specific scenarios: when the agent needs a vendor's own query language, when it needs a vendor's own permission model, and when it needs to navigate one application's internal hierarchy. In each case the unified model is the wrong shape for the task and the native endpoint is the right one.
The rest of the case against unified APIs for agents describes design choices that some unified APIs made and others didn't: intersection-only schemas, no field selection, no vendor vocabulary in the tool descriptions. This post covers how to test for each one, and how Unified.to answers them.
Where the argument is right
These three are real, and no unified model solves them. A vendor arguing otherwise is describing their schema rather than what the task needs.
Vendor query languages. An agent running project = BACKEND AND status changed FROM "In Progress" TO "Done" AFTER -7d needs JQL. A unified text search is not a substitute, and neither is a filter parameter. JQL is a query expression, not a filter. The same holds for SOQL and Workday's XPath-based queries. That request belongs on the native endpoint, and the response comes back in the vendor's shape rather than a unified object. That is a real trade on that call.
Permission and access audits. Answering "does this user have admin access to Salesforce?" requires Salesforce's own profile and permission-set model. A flattened role: admin field means something different in every integration and is the wrong shape for a compliance answer. Microsoft Graph makes the point sharpest: it separates delegated and application access at the token and flow level, so one token does not operate as both. That distinction cannot be normalized away, and an agent that ignores it gets a partial answer that looks complete.
Navigating one application's hierarchy. Finding a named file inside a specific SharePoint site's library structure needs SharePoint's own model of sites, libraries, and inherited permissions. A generic folder shape loses the context the agent needs to navigate. The same applies to Confluence spaces and Notion's database-page-block structure.
What determines whether these three are workable or fatal is not the unified model. It is whether the native path runs on the same authorized connection, or whether reaching it means a second integration, a second credential, and a second thing to maintain.
On Unified.to it is the same connection: the Passthrough API executes against the vendor's own endpoint, and the unified response carries the original object ID in raw.__id, which is what the native request needs. The agent reads through the category model and drops to native for the call that requires it, without leaving the connection.
Does a unified model strip the fields an agent needs?
Only if it was built as an intersection. The claim is that a unified API can expose only the fields shared across every integration it supports, so each new integration shrinks the model, and by fifty integrations you are down to what they all have in common.
That is true of globally normalized models. It is a schema design decision, not a property of unified APIs, and it is testable in about a minute.
The screening question: ask a vendor for readable field counts per integration on the same object. An intersection model returns identical counts, because that is what an intersection means. Varied counts mean the model is not an intersection.
Unified.to's published ATS matrix, on the same unified objects:
| Greenhouse | Bullhorn | Ashby | Lever | Workable | iCIMS | JazzHR |
|---|---|---|---|---|---|---|
| 101 | 81 | 79 | 77 | 74 | 47 | 35 |
| Field counts are a screening question, not a verdict. They tell you the model isn't an intersection; they don't tell you whether the normalized meaning holds across integrations, whether enums survive, or whether writable-field parity is real. The follow-up questions are what happens to everything outside the unified shape: |
| What you need | What to ask for |
|---|---|
| The vendor's own object | A parameter returning original fields alongside the unified object |
| One specific vendor field | Field-level access to the original payload, not all-or-nothing |
| Custom field values | Values carried on the object, with their type attached |
| Vendor-specific endpoints | Native endpoint access on the same connection |
| Vendor-specific writes | Original fields accepted in the write payload |
On Unified.to: fields=raw returns the original fields alongside the unified object, raw.fieldname returns one of them, custom values arrive on the object with their format attached, native endpoints become callable MCP tools through include_external_tools, and writes accept a raw block. The unified model is the default path rather than the ceiling. Whether a given vendor answers the same way is the thing to check. |
Do unified objects waste an agent's context window?
Normalization reduces context substantially, and the strongest version of the case against unified APIs concedes it. StackOne, which built a unified API before moving to an action catalog, published the comparison: an employee record running approximately 17,000 tokens in Workday's native SOAP format compresses to approximately 600 tokens against a unified model, which they describe as one of the clear wins of the unified approach.
The remaining objection is narrower: a unified model returns every normalized field whether the agent needs it or not. That is true of the default and false of the capability. fields=id,name,emails returns three fields, and it composes any intent at call time. An agent planning a compensation review asks for name, salary, manager, and last review date and gets four fields rather than fifty.
The honest cost: in application code a developer hardcodes that field list. In an agentic system the model chooses it, and a model that guesses short has to make a second call. That is a real tax, and it is the trade against hardcoding task-scoped actions at build time. The mitigation is that the field list is an enumerated array in the tool schema, so the model selects from a published set rather than inventing names.
Does a unified schema fight the model's training data?
Partly, and this is the strongest objection in the argument. Models have read Salesforce's, Workday's, and Jira's documentation. Renaming Worker to employee does work against that prior.
Three things narrow it.
The prior is concentrated. Salesforce, Workday, and Jira have decades of public documentation. The long tail of ATS, HRIS, and accounting integrations that mid-market customers actually run has close to none. For those, native semantics puts the agent in front of an unfamiliar schema at runtime with no training advantage and no consistency either.
The prior is a snapshot. It reflects documentation as it existed during training, not the API as it behaves this quarter. Endpoints get deprecated and enums change. Recall is not currency.
And the vocabulary gap is a schema annotation, not an architecture. Tool descriptions can carry the vendor's own terms alongside the unified ones. On Unified.to, the aliases parameter generates extended tool descriptions specifically to improve tool matching. The model's prior gets satisfied rather than contradicted, and the cost is a description field.
What this doesn't do is make mapping free. The agent still translates user intent into the unified vocabulary, picks an object, and selects fields. A unified model doesn't eliminate model-side reasoning; it moves the cross-integration semantic reconciliation into maintained code. An agent reading candidates across four ATS integrations against native schemas holds four vocabularies and decides at inference time that one integration's active and another's In Progress mean the same thing for this task, on every call, non-deterministically, with tokens spent each time. Against a category model, that reconciliation was written once and reviewed once.
And the counter-argument is real: a well-built action catalog doesn't have to expose vendor enums to the model either. It can ship update_candidate_status(status="active") with deterministic code translating to each vendor underneath. That works. It is also a unified model with a different name: one status vocabulary, consistent across integrations, deterministic translation. The question was never whether to normalize. It is which layer, and whether the vendor's own vocabulary stays reachable when the normalized one isn't enough.
What does the unified-first default actually cost?
The escape hatches accumulate a grammar of their own, and a model has to learn it.
On Unified.to, raw means five things depending on position: return the vendor object (fields=raw), return one vendor field (fields=raw.customfield1), recover the original object ID (raw.__id), pass native query parameters (?raw=status%3Dactive), or write vendor fields ("raw": {...} in the payload). That last one is a query string URL-encoded inside a parameter value, which is exactly the kind of nesting the case against unified APIs warns about. A model has to construct it correctly.
It is one token doing five jobs rather than a filter language plus an include syntax plus expand paths, which is the trade. But "no grammar to learn" would be false, and the four-step chain a model runs to use it is real work: know the unified schema, recognise it's insufficient, know the hatch syntax, then know the vendor's own field names.
Two things reduce it rather than remove it. Custom field values arrive on the object with their slug and format attached, so no hatch is needed to read them. And native endpoints surfaced through include_external_tools are separate MCP tools the model selects from a list, not syntax it composes mid-call.
How do you tell which kind of unified API you're dealing with?
- Are per-integration field counts identical or varied on the same object? Identical means an intersection model. Varied means it isn't. This is a screening question, not a verdict.
- Is there an escape hatch to vendor fields and endpoints on the same authorized connection? If reaching native means a second integration, the unified model is a ceiling.
- Can the agent control what it receives? Field selection specified on the request, from a published field list rather than a guess.
- Can tool descriptions carry the vendor's own vocabulary? If not, the training-prior objection lands.
- When the unified model is the wrong shape for JQL, permissions, or hierarchy, what is the documented path to native, and does it use the same credential?
→ Start your 30-day free trial
FAQ
Why do unified APIs fail for AI agents? Unified APIs fail for AI agents in three scenarios: vendor query languages like JQL and SOQL, permission and access audits requiring the vendor's own model, and navigating a single application's internal hierarchy. In each, the unified model is the wrong shape and the native endpoint is the right one. The broader claim that unified APIs fail categorically describes design choices that some unified APIs made and others didn't: intersection-only schemas, no field selection, no vendor vocabulary in tool descriptions.
What is the unified API lowest common denominator problem? The lowest common denominator problem is when a unified model can represent only the fields shared by every integration it supports, so each additional integration shrinks the model. It is a consequence of global normalization rather than a property of unified APIs. The screening test is to ask for readable field counts per integration on the same object: an intersection model returns identical counts, a category-scoped model returns varied ones. Varied counts don't prove the normalized meaning holds. That needs separate checking.
Should you use a unified API or a native API for AI agents?
Use a category-scoped unified model when the agent reads or writes the same object across several integrations, and the native API when it needs the vendor's own query language, permission model, or hierarchy. The decision is per task, not per architecture. What matters is whether both run on the same authorized connection: on Unified.to an agent can list candidates through the unified ATS model and reach the native endpoint through the Passthrough API, using the original object ID returned in raw.__id, without a second integration build.
How do unified APIs affect an agent's context window? Normalization reduces context substantially. By StackOne's published figures, an employee record drops from approximately 17,000 tokens to approximately 600. Whether the agent receives every normalized field or only what it needs is set by a request parameter rather than by the architecture. The cost specific to agents is that the model chooses the field list rather than a developer hardcoding it, so a model that guesses short pays for a second call.
Does a unified schema conflict with an LLM's training data? It differs from the vendor vocabulary a model saw during training, which matters most for the few applications with heavy documentation coverage and barely at all for the long tail. A training-era prior is also a snapshot rather than a guarantee the API still behaves that way. Tool descriptions can carry the vendor's own terms alongside the unified ones, which is a schema annotation rather than an architecture change.
What should you evaluate when choosing integration infrastructure for AI agents? Five questions: Are per-integration field counts varied or identical? Is there an escape hatch to vendor fields and endpoints on the same authorized connection? Can the agent control what it receives through field selection? Can tool descriptions carry the vendor's vocabulary? And when the unified model is the wrong shape, what is the documented path to native, and does it use the same credential?
Author
Written for Unified.to by Mallory Greene
About the author: Mallory Greene is a writer specializing in generative engine optimization (GEO) and content, through her practice Search Everywhere. She covers integration infrastructure and technical content across Unified.to's technical content library. Based in Toronto.