API adapter: what it is and how it connects your systems

The translation problem, concretely

Take the most ordinary integration in B2B: getting Stripe charges into QuickBooks as invoices. Both systems are well documented, both have official SDKs, and they still disagree about everything:

Stripe sends	QuickBooks expects	The adapter's job
amount: 12900	TotalAmt: "129.00"	Minor units to decimal string
created: 1767225600	TxnDate: "2026-01-01"	Unix time to date, books timezone
customer: "cus_9x2"	CustomerRef: {value: "58"}	Cross-system ID lookup, create if missing
currency: "usd"	CurrencyRef: "USD"	Case and enum normalization
Bearer key, flat REST	OAuth 2.0, refresh every 60 days	Two auth models, renewed automatically

None of this is hard individually. All of it together, done reliably at 3 a.m. on a Saturday, is an engineering project. That project is the adapter.

The five jobs of a production adapter

Translation is the visible job. Production adapters carry four more:

• Auth that renews itself. OAuth refresh tokens expire, API keys rotate, scopes change. The adapter owns the credential lifecycle so no one writes another token-refresh cron.
• Pagination. Stripe uses cursor-based starting_after, HubSpot uses after offsets, older APIs use page numbers. The adapter walks whatever the API offers and presents one stream of records.
• Rate limiting. When the API returns 429, a naive script drops the batch. An adapter reads the reset window, queues, and resumes. Salesforce's daily API quota has ended more integrations than any bug.
• Retries with idempotency. Failed writes retry with exponential backoff, keyed so a retry never creates a duplicate invoice. Duplicates are worse than gaps: gaps get noticed.
• Schema tracking. APIs version and fields move. The adapter is the one place that absorbs the change, instead of six scripts breaking in six ways.

Adapter vs SDK vs integration script

The terms blur, and the differences decide maintenance cost. An SDK is a client for one API: it makes calling Stripe pleasant, and knows nothing about where the data goes. An integration script is two SDK calls and some field assignments in between; it works until either API changes, and it embeds the mapping in code only its author can safely edit.

An adapter makes the in-between part a first-class, declarative thing: the mapping is data, not code, so it can be reviewed on a screen share, versioned, and changed without a deploy. The name comes from the classic software adapter pattern, and before that from hardware: a plug that lets two incompatible ports connect without rewiring either device. That is the correct mental model. Both systems stay stock; the adapter absorbs the mismatch.

This is also the unit an integration platform is built from. When we explain what iPaaS is, the honest answer is: managed adapters, plus scheduling and monitoring around them.

When you need one

• Two systems must agree about the same records over time (CRM and marketing, payments and books, store and ERP). Agreement needs dedupe keys and idempotent writes, which scripts rarely have.
• The sync must survive failure. If a missed record means a missed invoice, "the cron died Tuesday" is not an acceptable postmortem.
• More than one person needs to understand the mapping. Field logic buried in a script is tribal knowledge with a bus factor of one.

How records actually move through an adapter, from trigger to mapped write, is a short read: see how does data integration work. The trigger side, push vs pull, has its own tradeoffs covered in webhooks vs polling.

Build or buy

Building the Stripe-to-QuickBooks adapter above is a 2 to 6 week project for one engineer, and then a permanent tax: the rule-of-thumb maintenance cost is 20% of an engineer's time per integration, forever. A realistic maintenance year for that one adapter looks like this:

• QuickBooks minor-version release changes the validation on DocNumber; rejected writes pile up for two days before anyone looks.
• Stripe ships a new API version; your pinned version keeps working, but a new event field your team wants means a migration and a re-test of every transform.
• The OAuth refresh token is invalidated when an admin changes the connected QuickBooks account's password. Syncs stop; the fix is a manual re-auth nobody documented.
• A customer with 40,000 historical charges connects, and the naive backfill loop hits the rate limit and starves the live sync behind it.

None of these are exotic. Each one is an afternoon to a week of engineering, and they arrive whether or not the roadmap has room. A prebuilt api connector for the same pair costs minutes to configure, because the five jobs are already done and tested across every customer running that pair.

The build case survives only when the integration is your product's differentiator. For everything else, the pattern is the same one hardware settled decades ago: nobody solders their own plug. On a data integration platform, the adapter is the thing you configure, not the thing you write.