The integration is the product, more often than not.
A booking site is a calendar service, a payment processor and an email provider with a design on top. The value is in what happens between them.
That work is invisible while it runs and extremely visible when it stops. An order that took payment but never reached the warehouse, a lead that vanished between the form and the CRM, a booking that exists on the site and not in the diary: each one is a service having answered and another not having heard.
We build the connection as the thing it is: a piece of software with its own failure modes, its own record of what happened, and its own way of catching up after an outage. Not a call bolted to the end of a form handler.
Every integration works on the day it ships. The question is what it does at 3am six months later.
Four things we do every time.
Write it down first
The transaction is recorded on our side before any third party is called. If the service is down, nothing is lost. There is a record waiting to be delivered rather than a gap where an order used to be.
Retry, then escalate
Failures are retried on a schedule that backs off, and anything still undelivered raises an alarm with a person named on it. Silence is treated as a fault, not as good news.
Reconcile
A scheduled job compares both sides and reports what does not match. Most integration bugs are discovered by a customer; this is how they get discovered by us first.
Hold the credentials properly
Keys live in a managed secret store with rotation, never in the codebase or a configuration file. Each integration gets only the scopes it needs.
If it has an API, it can be connected.
Stripe, Authorize.net and PayPal for payment. HubSpot, Salesforce and Zoho for CRM. ShipStation and the carriers for fulfilment. Twilio and SendGrid for messaging. QuickBooks and Xero for accounting. Google and Mapbox for mapping and places.
Where a service has no usable API, there is usually still a way: a scheduled file exchange, a webhook, a reporting endpoint. Those are less pleasant and we will say so before quoting them rather than after.
- Delivery
- Durable write, then dispatch
- Failures
- Backoff with a dead-letter queue
- Credentials
- Managed secret store, rotated
- Monitoring
- Alarms on undelivered age
Beyond the connection itself.
A record of every exchange
What was sent, what came back and when. When a third party says they never received something, the answer is a log entry.
Somewhere to look
Failed deliveries are visible without reading server logs, and they can be retried without a deployment.
Rate limits respected
Calls are queued and paced to the provider’s published limits, so a busy day does not become a blocked account.
Replaceable parts
Each integration sits behind a boundary of its own. Changing payment provider is one adapter, not a rewrite.