Best Unified API Providers for B2B SaaS

A unified API is a single set of objects, such as employee, candidate, contact, or invoice, mapped onto many products. Your app integrates once. Each customer's Salesforce, HubSpot, Workday, or NetSuite is supposed to look like that one model.

The trade-off is in the mapping. The common model keeps what the unified vendor decided was shared. It drops, or shoves into an untyped bag, the fields that only one provider has. For a directory sync, that is often fine. For an agent that has to set the field your customer actually uses, it is the bug. This page is about that loss: which fields go, and when you should not accept it. Counts and architectures below follow public vendor descriptions as of October 2026. Where two vendors disagree about a competitor's coverage, the count is left out.

What normalisation removes

A common "deal" or "employee" object has a name, a status, and a handful of dates. The provider-specific remainder does not fit:

Custom objects and custom fields. The customer's Salesforce org, or their HRIS, has objects the common model has never heard of. Some platforms expose a generic custom-field map. Many only do that on a higher plan, and the agent still has to know the provider's name for the field.

Write actions that do not map. Creating the standard record works. The provider's own action, the one that posts a payment application or advances a hiring stage the common enum does not contain, does not. The call either fails or silently skips the step.

Status values and enums. One CRM's stage names are not another's. The unified enum collapses them. Reporting still works. An agent that must set the exact stage the customer's process uses does not.

Nested records the common model flattened or omitted. Line items, attachments, and provider-only child objects are the usual casualties. A read of the parent succeeds. The child the workflow needed is absent.

Passthrough, sometimes called a proxy call, is how these platforms give the field back. You send the provider's own request through their pipe. You have the field. You no longer have one schema, one error shape, or one auth model for that call. Passthrough is an escape hatch, not a unified API.

The second split is when the data is read. Sync-and-store platforms keep a copy and answer from it. The copy can be minutes or hours old. Pass-through platforms call the provider when you call them. The data is current, and a provider outage is your outage.

The providers

Merge. The broad option for HRIS, ATS, CRM, accounting, ticketing, and file storage. It syncs a normalised copy and serves reads from that copy. That is a good fit for product analytics and for objects that are the same across customers. It is a poor fit when the agent must read or write a field Merge did not put on the common model, or when the data has to be current within seconds. Passthrough exists for the missing call. Using it means that call is no longer the unified schema. Merge is the default when the common objects really are enough.

Apideck. Category coverage with request-time reads rather than a synced copy, plus a proxy for provider endpoints that are not in the unified model. Choose it when staleness is unacceptable and you still want a common read model for the standard objects. The proxy is the same trade as every passthrough: the provider-specific field is available, and your code now speaks that provider.

Unified.to. Pass-through by default. Their October 2026 description says calls go to the source system and they do not store customer records for the integration. Logs they describe are operational, not full payloads. Choose it when keeping a copy of customer HR or CRM data in a third party is the objection, and you can live with the common model's gaps. Provider-only fields are still not in the common objects. You did not gain them by avoiding the cache.

Nango. Closer to a toolkit than to a fixed common model. You build the integration, including auth and the mapping, and you can self-host. The fields that survive are the ones you mapped. That is the right trade when the "unified" part is your own model, not a vendor's, and you accept the engineering. It is the wrong trade when the goal was to stop writing per-provider code.

Kombo and Finch. Specialists, not general B2B catalogs. Kombo is HR systems, especially European ones, and serves reads from its own synced data. Finch is US employment and payroll, and also answers from the latest successful sync unless you are on a plan that forwards the request. The common model is deeper inside that one domain and still drops whatever the employment system does that the model does not name. Pick a specialist when the product is HR or payroll. Do not pick one and then expect a CRM.

Codat. Accounting and commerce data, served from a cache. Invoices and payments that match the common model are the point. A provider-specific ledger field is the thing you will not see until you step outside it.

Truto. A real-time proxy with a normalised model and a raw path beside it. Aimed at products whose agents must act per customer, including fields that differ by tenant. The raw path is again a passthrough. Use it when you know you will need both, and budget for two ways of calling.

When the lost field matters

It matters when the agent's job is the exception, not the directory.

A support agent that updates "the status" can live on a common enum. A support agent that must set the customer's own Salesforce stage, or write a custom object their ops team invented, cannot. The unified call will succeed and do the wrong thing, or it will force a passthrough that your tests do not cover.

It matters on writes more than on lists. A nightly employee sync can ignore a custom compensation component. A write that is supposed to change that component cannot ignore it. The row will look updated in your app and unchanged in the system of record.

It matters when the copy is stale and the agent tells a person the current value. Sync intervals are a product property, not a rounding error. If the action depends on the value right now, a synced unified API is the wrong read path.

It does not matter when every customer uses the same small set of fields and you control the UI. Then the common model is the product, and passthrough is a smell.

Where Swytchcode sits

Swytchcode is not a unified API and it does not join this list as one. It is an execution kernel. The agent calls the provider's own method. Nothing is mapped onto a common employee or deal, so a provider-specific field is still there, because the schema is the provider's schema. You do not get one integration for every CRM. You get one governed call per method you allow.

That is the direct side of the trade. The runtime checks the allow list, validates input against the real schema, evaluates policy before injecting the credential, and sends the request straight from your machine to the provider. Sandbox or production is the project mode in tooling.json, set once at swy init. Retries back off on rate limits. A POST or PATCH is retried only when an idempotency key is set. The response is validated on the way back. Method names come from swy discover, scoped with --project, after swy get. Do not hardcode one. The stages are in AI agent execution layer architecture. Auth for those calls, when the token must not enter the model, is credential brokering.

Use a unified API when the common model is the feature you are selling. Use direct execution when the field the customer cares about is one the common model dropped. Some products need both: unified reads for the standard objects, and a governed direct call for the write the model cannot express. Do not send that write through passthrough and also through an ungoverned HTTP client. One of those paths will retry it wrong.

FAQ

What is a unified API?

One schema your application calls, mapped to many providers in a category. You integrate the category once. Each mapping decides which provider fields appear.

Which fields do you lose?

The ones the common model does not define. Custom objects, provider-only properties, enums that were collapsed, and writes that have no common action. Passthrough can reach them. That call is no longer unified.

Is a synced copy the same as a lost field?

No. A synced copy can contain the common fields and still be old. A lost field is absent even when the copy is fresh. Check both before you trust an agent to tell a customer the current value.

Does Swytchcode replace Merge or Apideck?

No. Those products sell a common model across many providers. Swytchcode runs the provider's own API under policy, auth, and retry rules. You keep the provider's fields. You do not get a single schema for every vendor in a category.

When should a B2B product use passthrough?

When a specific customer needs a field or action the common model lacks, and you are willing to own that provider's schema for that call. If most calls are passthrough, you bought a pipe, not a unified API.