What a unified API is, and when you need one

Most B2B software reaches the same moment. A customer asks for a QuickBooks Online integration. You build it. Then a prospect asks for Xero, then NetSuite, then Sage Intacct. Each one has its own auth, its own objects, its own errors and its own idea of what an invoice is.

A unified API is one answer to that moment. This post explains what it is, what it buys you, what it costs, and how to tell whether your product needs one yet.

The short definition#

A unified API is one interface and one data model over many similar platforms. You call one endpoint, such as GET /v1/finance/invoices, and the provider translates that call to QuickBooks Online, Xero, NetSuite or whichever system your customer connected.

The response has the same shape whatever the source. Field names, types, enums, pagination and errors are normalized. Only a few fields change between platforms, typically the platform name and the platform's own record id.

{
  "id": "inv_01JC8Q2K7M",
  "object": "invoice",
  "platform": "xero",
  "remote_id": "6c4f1e2a-0b7d-4f7e-9a51-2d8c3b9e1f04",
  "number": "INV-1047",
  "status": "open",
  "currency": "USD",
  "total": "1931.04",
  "amount_due": "1931.04"
}

Under the hood, a unified API usually bundles four things:

1. Auth. An embeddable flow that handles OAuth, API keys or installed agents, plus token refresh and revocation.
2. A common schema. Objects such as Invoice, Bill, Payment, Order and SKU, mapped from each platform.
3. Sync and events. Scheduled or incremental sync, and webhooks when records change.
4. Operations. Logs, retries, rate limit handling and alerts when a connection breaks.

What it buys you#

One integration in your product#

Your code talks to one schema. When you add a platform, you usually change configuration, not application logic. The tenth accounting integration costs far less than the first, because the first one paid for the abstraction.

Less maintenance#

Platform APIs change. Versions get retired, auth flows get tightened, fields get renamed. With a unified API, the provider absorbs most of that churn. Your team keeps calling the same endpoints.

Faster coverage for sales#

Integration gaps lose deals, especially when you move up-market and buyers run ERPs. A unified API lets you say yes to a platform list rather than one platform at a time.

Consistent operations#

One error model, one log format and one place to see which customer connections are failing. Support teams can answer "why didn't my invoice sync?" without reading five vendors' docs.

What it costs#

A unified API is not free in engineering terms either. Be honest about the trade-offs before you commit.

Abstraction loss#

A common schema covers what platforms share. Every platform also has fields and behaviors nobody else has: NetSuite custom records, Xero tracking categories, QuickBooks classes. A weak unified API drops these. A good one exposes the raw platform record, lets you map custom fields, and offers passthrough requests to native endpoints.

Ask any vendor: how do I reach a field you don't model?

Write-back depth#

Reading data is the easy half. Writing an invoice or a bill into someone's ledger is where integrations fail: closed periods, missing tax codes, invalid accounts, duplicate retries. Many unified APIs are read-first. If your product writes, check write support object by object and platform by platform.

Data handling#

Some providers store synced data, some pass every request through live, some let you choose. Storage makes reads fast and enables webhooks. Pass-through keeps sensitive data out of a third party's systems. Your security review will ask which model applies to each object.

Dependency#

You are putting a vendor between your product and your customers' systems. Ask about status pages, incident history, how they handle platform deprecations, and what migration would look like if you ever left.

Price#

Most providers price per connection, per customer or per API call. Model the cost at your expected scale, not at the pilot.

Unified API vs iPaaS vs building in-house#

These three get confused. A rough map:

iPaaS is a large category, an $8B+ iPaaS market growing more than 20% a year (Gartner, 2024), but most of it serves internal automation. If your end users connect their own systems inside your product, you are in unified API territory.

Building in-house is a real option. If you need one platform, deeply, and it is core to your product, a direct integration can be the right call. The cost shows up later, in maintenance and on-call, rather than up front.

Three signals you need one now#

1. Your integration backlog is longer than your team#

If sales keeps a list of "platforms we lost deals over" and engineering keeps pushing it to next quarter, the backlog is a revenue problem. A unified API turns a list of projects into a list of configurations.

2. You are moving up-market#

Small businesses run QuickBooks Online and Xero. Mid-market buyers run NetSuite, Sage Intacct, Dynamics 365 Business Central and Acumatica. Each ERP brings subsidiaries, dimensions and approval workflows. If your next segment runs ERPs, the per-platform cost jumps.

3. You need data that crosses categories#

A lending product wants the ledger, bank data and commerce sales. A commerce tool wants orders, inventory and payouts posted to the ledger. When one feature needs three categories of systems, a shared data model starts paying for itself.

When you don't need one yet#

You probably don't need a unified API if:

• You serve one market where one platform dominates, and it is enough.
• Your integration is a one-time import, not an ongoing sync.
• The integration is the product, and you need control over every edge case.

In those cases, build direct, keep the integration thin, and revisit when the backlog grows.

Questions to ask any provider#

• Which objects can I read and write, per platform, today? Is there a public coverage matrix?
• How do I reach custom fields and fields you don't model?
• Do you store data? Can I choose per object?
• How do retries work on writes? Do you support idempotency keys?
• What happens when a platform deprecates an API version?
• Can I white-label the connection flow?
• Can I get engineering help if my timeline is tight?

How Unify Int fits#

Unify Int is a unified API built on one data model, the Unify Graph, for finance and product data: accounting, ERP, payments, commerce, PIM, inventory and ads. Every object carries its raw record, writes support idempotency keys and validation, and you choose sync-and-store or pass-through per object.

We are in developer preview. Read the Unified API overview, check the coverage matrix, or request sandbox access.