The unified API buyer's guide

A unified API puts one schema and one authentication flow in front of many similar platforms. You write code against the unified model, and the vendor maintains the connectors underneath. The idea is simple. The differences between vendors are not, and they tend to show up months after you sign, when a customer asks for a NetSuite custom field or a write to a closed period fails silently.

This guide is a structured way to evaluate vendors before that happens. It covers the criteria that matter for finance, commerce and product data, the questions to ask, a scoring worksheet you can copy, and the red flags we would watch for if we were buying.

Start with your own requirements#

Before you compare vendors, write down three lists. They make every later conversation shorter.

1. Platforms, ranked by revenue. Pull the systems your customers and prospects run from your CRM, support tickets and lost-deal notes. Rank them by the revenue they touch, not by how often they are mentioned.
2. Objects and operations. For each platform, list the objects you need (invoices, bills, payments, journal entries, orders, SKUs, inventory levels) and whether you read, write or both.
3. Constraints. Data you cannot store, regions you must host in, approval rules your customers expect, and the latency your product can tolerate.

A vendor that covers forty platforms but not the three at the top of your list is the wrong vendor. A vendor that reads invoices everywhere but writes them nowhere is the wrong vendor if your product creates invoices.

The evaluation criteria#

Coverage depth, per object#

Platform counts are a weak signal. Ask for coverage at the level of object and operation: which objects are readable, which are writable, and which fields are populated on each platform. A good vendor publishes this as a matrix with a status per cell (live, beta, roadmap) instead of a logo wall.

Check field depth too. An invoice object that returns totals but drops line items, tax lines or tracking categories will not survive contact with an accounting product.

Read versus write#

Reading is list and get. Writing is create, update and delete where the platform allows. Many unified APIs are read-first, with write support on a subset of objects and platforms. Confirm write support object by object for the platforms on your list, and ask what happens when a platform does not allow a write: a typed error, a silent no-op, or a partial success.

Write safety#

Writing into someone's books is where integrations cause real damage. Look for:

• Idempotency keys on every write, so a retried request never creates a second invoice.
• Validation before submit, checking accounts, tax codes, currencies and periods against the target ledger.
• Closed-period handling with a clear, typed error rather than a generic failure.
• Approvals for writes above a threshold or from automated actors.
• An audit record with before and after values, the actor and the platform's response.

A write request should look something like this:

curl -X POST "https://api.unifyint.com/v1/finance/invoices" \
  -H "Authorization: Bearer $UNIFY_API_KEY" \
  -H "Unify-Connection-Id: conn_xro_3m9d7" \
  -H "Idempotency-Key: 7d1f0c2e-invoice-1048" \
  -H "Content-Type: application/json" \
  -d '{
    "customer_id": "cus_01JC8P9X4R",
    "issue_date": "2026-11-01",
    "due_date": "2026-12-01",
    "currency": "USD",
    "line_items": [
      { "description": "Install service", "quantity": "1", "unit_amount": "450.00", "account_id": "acc_01JC7Z1H2B" }
    ]
  }'

Note the amounts as decimal strings. Floats and money do not mix, and a vendor that returns amounts as JSON numbers is telling you something about how carefully it thought about finance.

Data storage model#

Vendors either store a synced copy of your customers' data (sync-and-store) or fetch it from the platform on every request (pass-through). Storage makes reads fast and enables change webhooks. Pass-through keeps sensitive data out of a third party's database. The best answer is often a choice per object: store catalogs and orders, pass through ledger detail. Ask which model the vendor uses, whether you can choose, and what is retained in logs either way.

Authentication and white-label#

Your customers will see the connection flow. Check whether it can carry your brand, run on your domain and request only the scopes you need. Ask who owns the OAuth app credentials for each platform. This matters more than it seems: if the vendor owns them, moving away later usually means asking every customer to reconnect.

Webhooks and sync#

Ask how fresh data is per platform and how changes are detected: platform webhooks, polling, or a mix. Check that webhooks are signed, retried with backoff and replayable. Ask whether you can set sync frequency per object, because the chart of accounts and open orders change at very different rates.

Monitoring and support signals#

When a customer's connection breaks, your support team needs to know before the customer does. Look for request logs with the underlying platform request and response, webhook logs with replay, sync history, and alerts for expired tokens and failing syncs, searchable by customer.

ERP depth#

Mid-market deals turn on ERPs. NetSuite, Sage Intacct and Dynamics 365 bring subsidiaries, dimensions, custom fields, custom records and approval workflows. Ask how each is modeled. Ask for an example of a NetSuite custom field mapped into the unified object, and how a write enters an ERP that has approval rules.

Product data#

If your product touches commerce, check whether catalog, inventory and orders sit on the same model as finance data. Margin by SKU, stock value and ad spend per order all cross the two. A vendor with separate models for each forces you to do the joins.

Escape hatches#

No unified model covers everything. Look for three ways out: the raw platform record attached to each object, custom field mapping per connection, and passthrough requests to native endpoints that reuse the connection's auth and logging.

AI agents and MCP#

If you plan to let AI agents act on customer data, ask whether the vendor exposes integrations as tools through the Model Context Protocol (MCP), and how those tools are governed: scoped per agent, with amount limits, human approval for writes and an audit trail for every call.

Security#

Ask for encryption details (in transit and at rest), how tokens are stored, how tenants are isolated, where data is hosted, staff access controls and the current compliance status in writing. Do not accept a badge on a homepage as the answer.

Pricing model#

Common units are per connection, per API call or per platform. Per-connection pricing is predictable; per-call pricing can punish the sync patterns that make data fresh. Ask about platform surcharges, minimums, overage and what a sandbox costs.

Services#

Some teams want a platform. Others want someone to build the first integration, migrate off an old provider or keep things running. Ask whether the vendor offers implementation and managed services, whether the work runs on the same platform you would use yourself, and whether rates are published.

Questions to ask every vendor#

Send these in writing. The quality of the answers is itself a signal.

1. For each platform on our list, which objects are readable and writable today, and which are beta or roadmap?
2. Show us a full invoice response from QuickBooks Online and NetSuite. Which fields are populated on each?
3. What happens when we retry a write with the same idempotency key?
4. What error do we get when writing to a closed period?
5. Who owns the OAuth app credentials, and what happens to connections if we leave?
6. Can we choose sync-and-store or pass-through per object? What do you keep in logs?
7. How do you announce breaking changes, and how long is the deprecation window?
8. How do we reach a field you do not model?
9. What is your current compliance status, and can we see the report or letter?
10. What does a typical month cost us at 50, 200 and 1,000 active connections?

A scoring worksheet#

Weight each criterion for your product, score each vendor from 0 to 5, and multiply. The weights below are an example for a finance product that writes to ledgers; change them for yours.

Run a short proof of concept with the top two. Pick your hardest object on your most important platform, and include at least one write.

Red flags#

• Coverage you cannot see. A logo wall with no object-level matrix.
• "Full CRUD" without qualification. No platform allows every operation on every object.
• Amounts as floats. A sign the model was not designed for finance.
• No idempotency on writes. Retries will eventually duplicate records.
• Vendor-owned credentials with no exit plan. Leaving becomes a reconnect campaign.
• Breaking changes without dates. You will find out from your customers.
• Compliance by implication. Badges without documents.
• Pricing only on a call. Fine for enterprise contracts, a warning for a growth-stage plan.

How Unify Int fits#

Unify Int is designed around the criteria above: one data model, the Unify Graph, across accounting, ERP, payments, commerce, PIM and ads, with idempotent, validated writes, a per-object choice of sync-and-store or pass-through, and a public coverage matrix that shows read and write status per object. The platform is in developer preview, so ask us the same ten questions and hold us to the answers. You can compare approaches on our compare pages, see pricing, or book a demo to run a proof of concept on your hardest object.