API integration between systems that were never meant to meet

What an integration has to survive

API integration services are the work of connecting two pieces of software so that a record created in one appears correctly in the other. The connection itself is usually the easy part. What earns the fee is what happens when a request times out, when both systems hold a different version of the same customer, and when a retry could charge somebody twice.

A demonstration integration moves ten records between two systems while somebody watches. A production one moves forty thousand over a weekend, through a token that expired at three in the morning, against a partner service that returned errors for eleven minutes and then resumed as though nothing had happened.

The second was built against a list of conditions the first ignored. The list is short and it is close to identical on every project, which is why an integration quoted without reference to it is being quoted for the demonstration.

Pagination deserves more attention than it usually gets. If a list is read page by page using an offset, and records are created or removed while the read is in progress, the pages shift underneath the reader and records get skipped or read twice. Cursor-based paging avoids that. Where only offsets are available, reading in a stable order and reconciling counts afterwards is the workaround. A sync that quietly drops one record in a thousand is more dangerous than one that fails outright, because nobody goes looking for it.

• Authentication that expires, including tokens that refresh and keys rotated without warning
• Rate limits, which arrive as a refusal rather than a slowdown and have to be obeyed rather than retried immediately
• Pagination, including the case where the underlying list changes while you are reading it
• Retries with a growing wait and some randomness, so a recovering service is not knocked over by everyone reconnecting at once
• Idempotency, so a retry cannot create a second order or a second charge
• A record of every call made and received, because an integration you cannot inspect is one you cannot fix

The retry is the dangerous part

A request times out. The connection dropped somewhere between the request going out and the response coming back, which means the caller has no idea whether the other side did the work. Retrying may create a second order. Not retrying may lose the only one. There is no safe default, which is exactly why this has to be designed rather than assumed.

The standard answer is an idempotency key. The caller generates a unique value for the operation and sends it with the request, and the receiver stores it. If the same key arrives again, the receiver returns the original result instead of doing the work twice. Where the receiving system offers nothing of the kind, the equivalent is a check against a natural key before writing, such as an order reference or an external identifier held on the record.

This applies to anything capable of running twice, and in practice everything runs twice eventually. Most platforms deliver webhooks at least once, which makes a duplicate delivery normal operation rather than a fault. A consumer that is not safe to run twice will produce a duplicate invoice sooner or later, and it will do it on a Friday afternoon.

Two systems, each convinced it holds the truth

A customer's phone number lives in the CRM and in the accounting system. Somebody corrects it in one of them. A two-way sync copies the change across, the receiving system records an update, and that update looks like a fresh change that needs syncing back. Now the two systems are talking to each other in a loop, and the version that survives is whichever job ran last.

A cleverer sync does not fix this. What fixes it is deciding, field by field rather than record by record, which system is allowed to be right. The CRM may own the mobile number while the accounting system owns the billing address and the finance team's spelling of the company name. Written down, that takes an afternoon and settles arguments for years.

Reconciliation is the part that usually gets cut. A job that walks both systems every week and reports the records that disagree costs about a day to build, and it is the only thing that catches a sync which has been half broken since somebody renamed a field in March.

• A named system of record for each field, not for each object
• A marker on writes the integration makes, so its own echo is recognised and ignored
• Timestamps taken from the source system rather than from the moment the sync noticed
• One-way sync wherever the business can tolerate it, with a documented exception path
• A reconciliation job that reports disagreements instead of resolving them silently
• Deletions handled explicitly, because a record deleted on one side and edited on the other has no correct answer

When the system has no API

Plenty of software a business depends on has no public API, and some of it has one that is mentioned nowhere on the vendor's website. Asking costs nothing and works more often than people expect, sometimes as an undocumented endpoint and sometimes as a plan an account manager can enable for less than the workaround would cost to build.

Where there genuinely is nothing, the options run roughly in this order, best first.

Browser automation earns its warning label. It breaks when the vendor moves a button, it can conflict with the terms of the service being automated, it is hard to monitor because a page rendering differently is not an error, and it usually runs under a real person's login, so one resignation takes the integration with it. It has a place. It should be a deliberate choice with a review date attached rather than the first thing anybody reaches for.

• A supported export on a schedule, collected from a file drop or a mailbox and parsed
• Read access to a database or reporting replica, which is often available where an API is not
• A webhook the vendor supports for a narrow set of events, even without a full API
• Parsing the report the system already emails somebody every night
• Browser automation, which does work and belongs at the end of this list

Knowing it broke before your customer does

Integrations fail in two ways. They throw errors, which is the easy case, and they stop, which is the case that costs money. A job that no longer runs produces no errors at all, so a monitoring setup built entirely on error alerts will report perfect health while nothing has moved for a week.

Watching for absence is the fix. Every scheduled job reports that it ran, and the alert fires when a report fails to arrive rather than when one does. Expected volume matters as much: a nightly sync that normally moves a few hundred records and moved four last night has not failed, and something is still wrong.

The other half is a runbook. When a token expires at three in the morning, whoever is awake should not be reverse-engineering an integration they did not build. One page per integration saying what it does, what breaks it and what to do about each failure is a short document that decides how long an outage lasts.

• A heartbeat per scheduled job, with the alert on silence rather than on failure
• Record counts compared against what is normal for that day of the week
• Failed items sent to a queue a named person reviews, not to a log nobody opens
• Retries counted, because a rising retry rate is the early warning before an outage
• Alerts routed to a channel a human reads, naming the job and the record that failed

When an integration is the wrong fix

If two systems are being connected so that neither one has to be retired, the integration is rent on a decision nobody wants to make. It will be paid every month, and the decision will still be sitting there.

If the data on one side is unreliable, an integration distributes the problem faster and into more places. Cleaning once is cheaper than cleaning everywhere afterwards.

If the manual process being replaced is one person moving a dozen rows once a week, do the arithmetic first. Build cost plus ongoing maintenance against a few minutes of work is a calculation that sometimes says leave it alone, and a partner who never reaches that conclusion is not running it.

And if the vendor has announced that the API is being replaced, build against the replacement or wait for it. Integrating against something with a published end date buys a rebuild on somebody else's schedule.

What sets the price, and where an integration stops and asks

What it costs on an integration is decided before any code, by two answers. Whether both systems expose a documented API that permits writing as well as reading, and what happens when the two disagree. The first is a fact you can establish in a morning by reading developer documentation and testing a sandbox key. The second is a business decision about which system is allowed to be right, and agreement on it takes longer to reach than the connection takes to build.

No price is published here because the same two connectors between the same two products are a week at one company and a month at another, entirely on the state of the data and how many exceptions the finance team has been absorbing by hand.

Some things an integration must never resolve by itself. A payment appearing twice, a record existing in both systems under different owners, or a write that failed halfway through a batch. Each one waits for a person, with the payload and the timestamps attached, in a visible queue rather than an alert sent to an inbox nobody reads. Automatic retry is for a timeout. It is not for a conflict, and a system that quietly picks a winner in a conflict is generating a reconciliation problem for somebody in accounts three months later.

Ibrahim owns build and workflows, and this is his part of the company. Credentials sit in your own accounts, the connection inventory is written down at handover, and the workflows run on infrastructure you can host yourself. Building it internally is the right call when you already run an engineering team with these systems in their heads, and you will be told so on the call. What in-house teams usually want help with is not the happy path but idempotency and the replay tooling, which is a smaller and cheaper piece of work. Wobble stays accountable for the parts it built.

Common questions

What are API integration services?

API integration services connect two or more software systems so information moves between them without a person copying it. Most of the effort goes into the conditions around the connection rather than the connection itself: expiring authentication, rate limits, paging through large result sets, retries that must not duplicate anything, and monitoring that notices when the flow stops.

How long does an API integration take?

A single well-documented connection between two mainstream systems is usually days rather than weeks. What extends it is discovery: finding out which system owns which field, what the data actually looks like once you see all of it, and what the business wants to happen when the two sides disagree. Anyone quoting a timeline before seeing both systems is quoting the happy path.

What if the software we use has no API?

Ask the vendor first, because unadvertised endpoints and higher plans are common and often cheaper than the workaround. Failing that, a scheduled export collected and parsed, read access to a reporting database, or a webhook covering a narrow set of events will usually do the job. Browser automation works but breaks when the interface changes and often runs under one person's login, so it belongs last with a review date attached.

How do you stop two connected systems from overwriting each other?

Decide which system owns each field rather than which system owns each record, and write it down. Mark the writes your integration makes so its own echo is recognised and ignored, take timestamps from the source rather than from the sync, and run a reconciliation job that reports disagreements instead of quietly resolving them. Deletions need a stated rule of their own.

What does it cost to keep an integration running?

Less than building it, and never nothing. APIs change, credentials rotate, volumes grow past a rate limit that used to be comfortable, and the business changes what it wants a field to mean. Budgeting maintenance from the start is more honest than treating the first breakage as a surprise.

Should we use an automation platform or write custom code?

A platform such as n8n, Make or Zapier is the right answer for most business integrations, because the logic stays readable by somebody other than whoever built it. Custom code earns its place where volume is high, where latency has to be low, or where the transformation is complicated enough that a visual workflow becomes harder to read than a function. Settle first who maintains it in two years.