API Integration: How It Works

A two-person RevOps team I talked to last year had seven API integrations holding their stack together. Stripe to HubSpot, HubSpot to their data warehouse, Zendesk to Slack, and four more. None of them had been built by an engineer who still worked there. When a payment API version was deprecated, billing status quietly stopped flowing into the CRM for nine days before anyone noticed. That's the part nobody tells you about API integration: building it is the easy 20%, and keeping it alive is the other 80%.

This post covers what it actually is, how the request-response cycle works under the hood, the tools people use to build integrations, and a few real examples. Then it gets to the question most articles skip. Should a team under 200 people be writing and maintaining integration code at all?

What API integration is and how it works

An API integration connects two or more applications through their APIs so they can pass data back and forth automatically. The API (application programming interface) is the contract each tool publishes: a set of endpoints you can call to read or write its data. When you book a flight and the page shows hotel options, an API is delivering hotel data from one system to another. The integration is the code that calls those endpoints in a useful order and does something with the results.

Under the hood, almost every integration runs on the same loop. One application sends a request to another's endpoint, and the receiving system returns a response. The request carries an HTTP method that says what you want to do. The four you'll use constantly:

• GET retrieves data, like pulling a customer record.

• POST creates new data, like writing a new contact.

• PUT or PATCH updates an existing record.

• DELETE removes one.

Each request also carries an endpoint URL, headers (including authentication), and sometimes a body with the data you're sending. The response comes back with a status code and any data you asked for. A 200 means success, a 404 means the record wasn't found, a 429 means you've hit a rate limit. Data usually travels as JSON. That's the whole mechanism. An integration is just a lot of these cycles strung together with logic in between: read the changed records from tool A, transform them into tool B's shape, write them, handle the failures.

That last clause is where the work hides.

Why teams build API integrations and the hidden maintenance cost

The pitch for building one is clean. Read from one system, write to another, stop copying data by hand. For a single flow it can feel like an afternoon of work. The first version usually is.

Then the long tail arrives. Authentication tokens expire and need refreshing, so you write token management. The destination rate-limits you at 100 requests a minute, so you add throttling and retries with exponential backoff so a burst of changes doesn't get dropped. A field comes back null that never used to, and your write fails silently. Then the vendor ships a new API version and deprecates the old one with 90 days' notice that lands in an inbox nobody reads. Every one of these is a separate small project, and they never stop arriving because the APIs on both ends keep moving.

Here's the honest version of the cost, the one that doesn't show up in the original estimate:

The build phase is the only one anyone plans for. The other two are where integrations rot. And for a small team, the maintenance phase has a brutal property: the person who wrote the integration is frequently gone by the time it breaks, so debugging starts with archaeology. I've watched a founder spend a full day reverse-engineering their own glue code from eight months earlier because the integration that synced trial signups had started skipping records and there was no log to say why.

None of this means building one is a bad idea. The data does need to move. The question is who should own the moving parts.

API integration tools: gateways, iPaaS, and custom code compared

There's a spectrum of ways to get an integration running, and they trade control for maintenance burden differently. Three approaches cover most of what teams actually use.

• Custom code. You write against each API directly in Python, Node, or whatever you run. Maximum control, maximum flexibility, and you own every line including the parts that break at 2 a.m. Best when the integration is genuinely unique to your business logic.

• API gateways. A gateway sits in front of your APIs and handles cross-cutting concerns: authentication, routing, rate limiting, sometimes transformation. Gateways are great infrastructure, but they manage traffic to APIs you're still responsible for integrating. They don't write the integration for you.

• iPaaS and low-code builders. Integration-platform-as-a-service tools give you a visual canvas to assemble integrations from pre-built connectors, with less code than rolling your own. The catch is that you've now adopted a platform with its own recipes to maintain and its own pricing model, often billed per-task or per-operation. For high-volume operational data, per-task pricing gets expensive fast, and you're still the one debugging when a recipe's connector lags behind an API change.

A quick way to place them:

What's missing from this table is the option most small teams actually want, which is to not own the integration layer at all. We'll get there.

API integration examples: connecting CRM, billing, and support data

The abstract version is easy to nod along to. Concrete examples make the value obvious. Here are three that show up in almost every SaaS company's stack.

Billing to CRM. A customer upgrades in Stripe. An integration catches the subscription change and updates the matching contact in HubSpot so the account record shows the new plan and MRR. Now sales and success see current revenue without opening the billing tool. Build this yourself and you're handling Stripe's webhook signing, HubSpot's property API, contact matching, and the case where the email in Stripe doesn't match the email in the CRM.

Support to CRM. A Zendesk ticket gets filed. An integration pushes it onto the customer's CRM record so the account owner sees support history alongside the deal. The interesting failures here are about identity: tickets keyed on one email, CRM records keyed on another, and the integration quietly creating duplicates when it can't find a match.

Deal to billing. A deal closes in the CRM. An integration creates the invoice or subscription in the billing system so finance doesn't re-enter it. This one is bidirectional in spirit. The deal triggers the billing record, and the billing record's payment status should flow back to the CRM. Most hand-built integrations do one direction and leave the return trip as a TODO.

The pattern across all three is the same. Each is a small set of fields that needs to stay consistent between two tools. None of them is technically hard. All of them are annoying to keep running, and the annoyance compounds with every new tool you add, because integrations scale point-to-point: connect five tools pairwise and you can end up maintaining ten separate links.

How to get API integration outcomes without building or maintaining code

Step back and look at what you actually wanted. Not the integration itself. You wanted Stripe data showing up in HubSpot, support tickets on the CRM record, billing in sync with closed deals. The integration code was always a means to an end, and for most operational data flows it's an end you'd happily skip.

This is the gap between building integrations and getting connected tools, and it's where managed tool-to-tool sync fits. You connect each tool once, map the fields visually, and a managed service runs the API calls for you. The parts that make hand-built integrations rot become someone else's job: auth and token refresh, rate limits, retries with backoff, schema discovery, and the breakage when a vendor ships a new API version. When the upstream API changes, the connector gets updated centrally instead of in your codebase. That's the model we built Oneprofile around. You get connected tools without owning a single API call. Field-level change tracking means only the fields that actually changed get written, and when a record fails you can see which one and why instead of discovering it nine days later.

I'll be straight about where this doesn't fit. If your integration encodes real business logic, like pricing rules, approval workflows, or a proprietary scoring model, that's your differentiation and you should probably own the code. Managed sync is for the operational plumbing: keeping records consistent between the SaaS tools you already pay for. That's the 80% that breaks and the 80% nobody wants to maintain. For a small team without a dedicated integration engineer, handing off that 80% is usually the right call.

The deeper point is one I keep coming back to. The reason "build vs. buy" feels hard for integrations is that the build cost is front-loaded and visible while the maintenance cost is spread out and invisible until something breaks. Estimate the whole curve, not just the first afternoon, and the math usually changes. Whatever you choose, decide it on the total cost of keeping the integration alive, not on how quick the first version looks.