Custom integrations

What we connect

Why integrations break, and what separates one that runs for five years from one that dies in month three

Almost every integration works on the day it's delivered. Both systems are up, the data is clean, the developer is watching. The difference between a good build and a bad one shows up months later, in what was done about the situations that weren't on the demo script.

The other system will be down.

Not might. Every API has maintenance windows and slow afternoons, and an integration that assumes the far end always answers will lose data the first time it doesn't. What you want is a queue: your side accepts the event, stores it, and keeps trying. Three hours of outage means three hours of orders landing when it returns, in order, with nobody phoning you.

Retries must not create duplicates.

This is the failure that costs real money and the one most often missed. A request goes out, the far end processes it, then the response gets lost on the way back. Your side sees a timeout and retries. Now there are two invoices, two charges or two contacts. The fix is idempotency: every operation carries a key you generate, the receiving system recognises that key as one it has already handled, and the retry returns the original result instead of a second record. Where the far end supports idempotency keys, use them. Where it doesn't, keep your own ledger and check before sending again.

Rate limits are a design constraint, not an error.

Every platform caps how often you can call it, and the cap that never bites in testing bites hard the first time someone imports 4,000 records. Batch where the API allows it, back off when you're told to, and treat a rate limit as a normal condition rather than an exception to log.

APIs get deprecated on their schedule, not yours.

Versions retire, fields change meaning, endpoints get replaced. A pinned version with nobody reading the changelog is a build with an expiry date, which is why integrations belong under managed support rather than being handed over and forgotten.

Credentials expire.

Tokens, certificates and app passwords all have lifespans. A good share of the integrations we're asked to rescue aren't broken code, they're an expired credential nobody was tracking, often created under the personal account of someone who has since left. Use service accounts, not personal logins, and put every expiry in a calendar.

Monitoring is the difference.

The worst failure isn't loud, it's silent. The sync stops, nothing errors visibly, and everything looks normal until a customer rings about an invoice they never received. Every integration we build gets a heartbeat: a record of when each job last ran successfully, an alert when it hasn't run inside its expected window, a visible queue of failures with reasons attached, and a way to replay them once the cause is fixed.

None of that is glamorous, and all of it is why one integration is still running in year five while another stopped in March and nobody noticed until June.

Plenty of integrations shouldn't be custom built at all

We'd rather say this on the page than in the third meeting.

If the sync is low volume, not critical to the money, and does something a connector already does, use Zapier or Make. A few hundred records a month from a form into a CRM, a notification when a deal closes, a spreadsheet row per booking. Those are solved problems, and a no code tool gives you a build in an afternoon and someone in the office who can change it without booking a developer.

Where that stops being sensible is fairly clear. Volume, when per task pricing costs more than the build. Money, when a duplicate or missed record shows up in your accounts or a customer's bank statement. Logic, when the transformation needs real rules or lookups against your own data. Timing, when someone is waiting on the result rather than a sync running every fifteen minutes. Ownership, when it all sits in one person's personal account.

Most businesses want both. Use the no code tool for the small automations that would otherwise never get built, and build properly for the flows carrying orders, payments or customer records. If enquiries land in a CRM first, our CRM consultants usually start there.

How we do it

1. We map the data, both directions, including which system owns the record when they disagree.

2. We agree scope and price.

Fixed number, dates in writing, failure handling included in the scope rather than added later.

3. We build against a sandbox and test the ugly cases: timeouts, duplicates, rate limits, bad data.

4. We monitor it after launch, because an integration nobody is watching is a future outage.

Who it's for, and who it isn't

It suits businesses rekeying the same data into two systems, anyone whose orders and accounts disagree at month end, and software owners whose product has to talk to something a customer already uses.

It isn't for a one off data migration, or for a sync a connector already handles well. We'll point you at the connector.

Why bring this here

Developers in house, who also run the servers the integration sits on. The rest of our software work is on the apps and custom software page.

We're still here in year two.

Support is where integrations survive or quietly stop. No lock in contracts, and the code and credentials are yours.

"Our last integration broke and nobody told us."

Almost always a monitoring gap rather than a coding one. We look at what you have before quoting a rebuild, because the answer is often a queue and an alert.