JOURNAL · May 3, 2026 · 4 MIN READ

"Just connect these two systems" sounds simple — the real engineering cost of API integration

The most underestimated request I get is "can you just connect system A to system B?" It sounds like 2-3 days of work. It's actually 2-3 weeks. Here's what API integration really involves, and when you should custom-build versus use Zapier.

"Can you sync orders from my website to my accounting software automatically? Should be simple, right?"

This is one of the most common requests I get — and the most underestimated. Clients see two systems with APIs and assume "connecting them" is a small script. In reality, 80% of the work isn't writing code. It's handling all the things that aren't in the documentation.

This post breaks down what API integration actually costs, and how to tell whether your case needs custom development or if Zapier or Make can solve it for a fraction of the price.

What "API integration" actually involves

To a client, "integration" is a single line connecting two boxes. To an engineer, it's six things:

  1. Authentication: How do you prove you have permission? OAuth, API keys, HMAC signatures? What happens when the token expires?
  2. Data mapping: Does "customer name" in system A map to the same field in system B? Are date formats, currencies, ID schemes consistent?
  3. Error handling: What if the other API goes down? What if the network drops? What if the data format silently changes?
  4. Rate limiting: The other system allows 60 requests per minute. You have 500 orders today. Now what?
  5. Sync strategy: Real-time, hourly batch, or scheduled pull? How do you prevent the same record from syncing twice?
  6. Logging and monitoring: Which sync just failed? How do you find out? How do you recover?

Put simply: writing the core logic takes a day; getting all six right takes two weeks. Clients evaluate whether the feature works. Engineers evaluate whether the system will still be running in six months.

Three tiers of API friendliness

Not every API is created equal. Here's how I categorize them:

Tier 1, friendly: clear docs, full SDK, webhooks

Examples: Stripe, Shopify, Slack, Google Workspace APIs, Notion, Anthropic, OpenAI

These integrations are relatively straightforward. The docs are concise, an official SDK exists, webhooks deliver events in real-time (no polling needed), and error messages make sense. A skilled engineer can typically finish a typical integration in 2-5 days.

Tier 2, workable: docs exist but lag, partial SDK, polling required

Examples: most regional SaaS products, niche international tools, the public API of most ERP systems

Documentation exists, but it lags one or two versions behind reality. SDKs cover only some endpoints. There are no webhooks, so you have to poll on a schedule. Time gets eaten by debugging — what the docs say and what the API actually returns aren't always the same. A typical integration takes 1-3 weeks, with most of the time spent troubleshooting rather than coding.

Tier 3, hellish: no docs, reverse engineering required, breaks anytime

Examples: certain payment APIs, government systems, web scraping (technically not APIs but equally painful), legacy systems with no updates in a decade

For these, I tell clients straight: "This isn't 'integration' — it's 'development.' Budget and timeline have to be estimated separately." The hardest part isn't the technical work — it's that "the other side changes a field six months from now and your system breaks." You have to design monitoring so you know immediately when it fails, and budget for ongoing fixes.

When to build custom vs. use Zapier

Many clients assume they need a custom API integration when Zapier, Make (formerly Integromat), or n8n would solve the problem. My rule of thumb:

Use Zapier / Make when

  • The sync logic is simple: A happens → B does something
  • Both systems are in Zapier's supported list
  • Triggers fire under ~1,000 times a month
  • No complex data transformation needed (no lookups, calculations, or conditional branches)

Example: "When a customer places an order in Shopify, send a thank-you email and add them to Mailchimp." — Zapier sets this up in 30 minutes for $20-50/month. No need to spend $1,500 on custom code.

Build custom when

  • One system isn't in Zapier's supported list (many regional SaaS, in-house ERPs, legacy systems)
  • High trigger frequency (Zapier gets expensive past tens of thousands of events per month)
  • Complex data transformation or business logic required
  • Strict error retry, audit logging required
  • Sensitive data you don't want passing through a third party

Example: "Sync ERP shipping data to website order status daily, then notify customers via messaging app." — ERPs usually aren't in Zapier, the volume is high, and customer ID lookups are needed. Custom build, quoted around $2,500-5,000.

A real cost breakdown

Here's a real project (details lightly altered): the client wanted orders from a marketplace, Shopify, and a physical POS system synced into a daily Excel report emailed to their bookkeeper.

Sounds simple. Actually:

TaskHours
Marketplace API auth (no official SDK, docs incomplete)1.5 days
Shopify API connection (this part was fast)0.5 day
POS export (no API, had to scrape backend CSV)1 day
Unifying data formats across all three (field names, dates, product IDs all different)1.5 days
Scheduling + email logic0.5 day
Failure notifications (alert owner via messaging when anything breaks)0.5 day
Testing (3-day continuous run to verify data accuracy)1.5 days
Documentation + handover0.5 day

Total: 7.5 days. Quoted around $2,000. The client's first reaction: "Isn't this just pulling data out?"

But what convinced the client it was worth it happened in week three — the marketplace renamed an API field and the integration broke. Because we built monitoring from day one, the owner got a notification within 30 minutes, and we had it fixed within 2 hours. Without monitoring, this would have surfaced at month-end when the bookkeeper asked "why don't the books balance" — by which point three weeks of data would be missing.

How to vet an engineer for API integration work

If you're hiring someone for an integration, these four questions reveal who actually knows what they're doing:

  1. "Have you actually worked with these specific APIs before?" — If not, multiply their estimate by 1.5
  2. "How will I know when something breaks?" — Engineers who design monitoring will answer directly; those who don't will say "it won't break"
  3. "If the third-party API changes, do you charge to fix the integration?" — This needs to be in the contract or you'll lose out later
  4. "What happens when data doesn't match between systems?" — Anyone who can answer this has actually built integrations before

In short: anyone will say "yes, we can do it"; the real test is whether it's still running six months later.

If you have two systems you'd like connected and aren't sure how, send us a message and we'll talk for 15 minutes. I'll tell you straight whether it's a half-hour Zapier task or a real custom build — and if it's custom, how to design it so it doesn't break in three months.

§ MORE · Keep reading
CONTACT · Get in touch

Sound like something worth a chat?
Get in touch.

Book a free call
Reply within 24hQuote and contract includedRemote friendlyEN · 繁中