INT
Integration engineering
The integration is not finished when it works. It is finished when it fails safely.
The short version
Connecting suppliers, payment providers, accounting systems and CRMs so data moves reliably — including on the days the other end is down.
Integration is easy to demonstrate and hard to operate. The API responds in the sales call. It responds at three in the morning too, usually. The engineering is in what happens the rest of the time.
What is included
Concretely, this is the work.
- Supplier and channel integrations, including undocumented and semi-documented APIs
- Payment provider integration with correct handling of retries, duplicate webhooks and partial failures
- Accounting and finance system synchronisation with reconciliation reporting
- CRM and marketing platform connections that do not silently drop records
- Retry, backoff, dead-letter queues and replay, so a three-hour outage at the other end costs you nothing
- Monitoring and alerting that tells you an integration is degraded before a customer does
- A written integration contract describing every field, every failure mode and every assumption
Approach
What you should expect to change
- Data that arrives, or an alert explaining why it did not
- Outages at the other end that no longer become outages at yours
- A written record of how the connection actually behaves
How we build integrations
We assume the other side will fail, respond slowly, change without notice, send duplicates, and occasionally return something that is not valid at all. Every one of these has happened to us, and each is a design requirement rather than a surprise.
So: idempotency keys so a repeated message is not a repeated booking. Queues so a slow supplier does not become a slow website. Dead-letter handling so a failed message is visible and replayable instead of gone. And an alert that names the integration and the failure rather than a generic error nobody reads.
Undocumented APIs
A large share of travel supplier integrations have no usable documentation. That is normal work: capture the traffic, map the behaviour, build a test harness against a sandbox or a recorded fixture set, and write the documentation that should have existed.
Questions about integration engineering
The supplier has no API documentation. Can you still do it?
Usually yes. It is slower and we will scope it as investigation first, then build, so you are not paying for a fixed price built on a guess.
Can you fix an integration somebody else built?
Yes, and it is common work. Most broken integrations are not broken in the connection — they are missing retry handling, idempotency or monitoring.
Also
Other things we build.
AI agents and workflow automation
Agents that carry a whole process end to end — reading the enquiry, checking availability, drafting the quote, escalating the parts a person should see.
Read more BKGBooking and reservation platforms
The system your revenue actually passes through — search, availability, quoting, payment, confirmation, amendment, cancellation. Built to survive the edge cases.
Read more OPSOperations and back-office systems
The platform your team lives in all day. Suppliers, jobs, staff, documents, margins, reporting — shaped around how you actually work rather than a generic template.
Read moreStart a conversation
Have a project like this?
Send us a paragraph describing what the system needs to do and what you are using now. We will come back with an honest view of whether it is a fit and roughly what it costs.