What I've Learned Integrating APIs

Looking back at my project history, API integration shows up in roughly half of everything I've shipped — Hubspot syncs, Shopify tooling, booking systems, payment flows, Meta Pixel setups, and more. It's quietly one of the most common things a full-stack developer actually gets hired to do, and it's rarely taught as its own skill. Here's what I've actually learned doing it repeatedly.

Read the Rate Limits Before You Write Code

This sounds obvious and I still see it skipped constantly. Before touching an integration, I check: how many requests per minute/hour am I allowed, what happens when I hit the limit (hard block vs. throttling), and does the API return a Retry-After header I should respect. Finding this out after your integration is already failing in production is a bad way to spend an afternoon.

Build a Thin Wrapper, Don't Scatter Raw Calls

Every third-party API integration I build gets wrapped in its own small service class or module — one place that knows how to talk to that specific API. The rest of the application never calls the third-party endpoint directly; it calls my wrapper.

Auth Token Expiry Is the #1 Silent Failure

OAuth-based integrations (Hubspot, most CRMs, many payment providers) issue access tokens that expire, plus a refresh token to get a new one. The number of integrations I've inherited where the refresh logic was missing or broken — working fine for weeks until the token quietly expired — is high enough that I now treat token refresh as a first-class part of the integration, not an afterthought.

Webhooks vs. Polling

If the API offers webhooks, use them instead of polling on a schedule — it's faster, cheaper, and puts less load on both systems. But webhooks come with their own responsibility: you need an endpoint that responds fast (acknowledge first, process after), handles duplicate deliveries gracefully, and verifies the payload actually came from who it claims to. I've had to add signature verification after the fact more than once — it should be there from the start.

When Polling Is Still the Right Call

• The API doesn't offer webhooks (still common with older systems)
• You need to reconcile state periodically anyway, regardless of events
• The integration is low-frequency and doesn't justify webhook infrastructure

Idempotency Matters More Than People Think

For anything involving money or bookings, a retried request must never create a duplicate charge or a duplicate reservation. I always design these integrations so the same request, sent twice by accident (a network blip, a user double-clicking, a webhook firing twice), produces the same result instead of two results. That usually means generating a unique request ID on my end and checking for it before processing.

Log Aggressively While Building, Trim for Production

During integration development I log the full request and response for every call. It's the fastest way to debug why a field came back empty or a status code doesn't match the docs. Before shipping, I scale that down — especially anything touching customer data — but I keep enough logging to actually diagnose a failure at 2am without needing to reproduce it first.

Takeaway

API integration work isn't really about any one API — it's a set of habits that transfer across all of them: respect rate limits, isolate the integration behind a wrapper, handle token expiry deliberately, and design for retries and duplicates from day one. Get those right and most integrations are straightforward, regardless of which service you're connecting to.