Connecting systems
We connect your application to CRMs, payment providers, online stores and internal systems, and plan for the day the other side fails or changes.
Getting two systems to talk is usually quick. Keeping them in step is the hard part. A payment provider sends the same notification twice and a customer is charged twice. A CRM is down for an hour and new leads go missing. A field means one thing in the shop and another in the warehouse system.
We read both sides’ documentation properly, try anything unclear in test accounts, and plan for what happens when a step fails. Then we make sure someone finds out when it does, instead of hearing about it from a customer.
Product teams
Your application needs to exchange data with a payment provider, CRM, accounting tool or partner API.
Agencies
A client’s website has to connect to their stock, booking or membership system, and that isn’t work your team usually does.
Operations teams
Staff copy data from one system to another by hand. It’s slow, and mistakes creep in.
What data moves in which direction, how often, what triggers it, and how each field in one system matches a field in the other.
Code that signs in to each system, stays within their usage limits and checks everything it receives, running in an account you control.
Incoming notifications (webhooks) are checked, recorded and processed once, so a duplicate or late message can’t change the data twice.
A log of what was sent and received, an alert when failures start piling up, and a list of anything that needs a person to look at it.
How to change passwords and keys, re-run failed updates, and what to check when the other system is down.
This is the sequence we use when another system sends us notifications. Each step knows what to do if it fails, so a problem stays contained instead of quietly losing data.
1
A public endpoint accepts the request.
If it failsProvider retries delivery on its schedule.
2
Signature and timestamp checked against the raw body.
If it failsRejected and logged; repeated failures alert.
3
Event stored with its provider ID before anything else.
If it failsEndpoint returns an error so the provider retries.
4
2xx returned within the provider’s timeout.
If it failsNothing is lost: the event is already recorded.
5
Events already processed are skipped.
If it failsUnique constraint prevents double processing.
6
Mapped and applied to the target system.
If it failsRetried with increasing delays.
7
Events that exhaust retries are held for a person.
If it failsAlert sent; event can be replayed after a fix.
8
A scheduled comparison corrects any drift.
If it failsDifferences reported for review.
Illustrative code
A simplified example written for this page, not code from a client project. It shows the choices we’d normally make.
// app/api/webhooks/inventory/route.ts
export async function POST(req: Request) {
const raw = await req.text() 1
const event = verifySignature(raw, req.headers, SECRET) 2
if (!event) return new Response(null, { status: 401 })
const inserted = await db.webhookEvents.insertIfAbsent({ 3
id: event.id,
type: event.type,
receivedAt: new Date(),
})
if (inserted) await queue.send("inventory.apply", event.id) 4
return new Response(null, { status: 202 }) 5
}
Webhooks, where the other system tells you when something changes, are faster and cheaper if it sends them reliably. Polling, where you ask it every few minutes, is simpler and sometimes the only option. Where the data has to be right, we usually add a scheduled check that compares both systems.
Tools like Zapier or Make work well for simple, common connections. Custom code is better when the data needs a lot of translating, there’s a lot of it, or errors need careful handling. If the simpler option will do, we’ll say so.
Each piece of data needs one system in charge of it. If two systems can both change the same thing, they’ll eventually disagree, and deciding the rule at the start is far cheaper than sorting out the mess later.
Instant updates are more complicated and more easily upset by outages. Plenty of processes work perfectly well with an update every few minutes, or once a night.
For both systems, including their limits and what they promise about notifications.
Small experiments in test accounts wherever the documentation is vague.
Which field goes where, how it’s converted, and which system is in charge.
Retries that back off, duplicate checks, and a holding list for anything that keeps failing.
Where we can, alongside the current process, comparing results before switching over.
Alerts set up, instructions written, and the keys in your accounts.
Every integration relies on someone else’s system, including its documentation, uptime, usage limits, prices and how often it changes. We can work around those limits but can’t remove them, and we’ll tell you about any that put the project at risk.
The full process, from first message to handover, is on How we work.
A regional logistics group, via its digital agency
A purchasing portal for a logistics group across Singapore and Malaysia: one place to request, approve and track every purchase, connected to the finance system.
The cost depends heavily on the other systems, and that’s also where the unknowns are. So we often suggest a short fixed-price first step to read the documentation and test the APIs, then estimate the build.
After a first call, we send a written quote that says what’s included and what isn’t.
Sometimes. There may be a partner API, an export feature, or a database we’re allowed to read from. Reading data off its web pages is a fragile last resort, and we’ll tell you if that’s the only way.
Providers usually announce changes in advance, and monitoring catches the ones they don’t. Updating the integration is maintenance work, which we can cover under a maintenance arrangement.
In your own hosting, usually as serverless functions alongside your application or as a small service in your cloud account.
They’re stored as secrets in your hosting platform, never in the code, and limited to what the integration actually needs.