Real-time API calls
When a booking has to be confirmed while the customer is still on the page. REST or GraphQL over HTTPS, with timeouts and fallbacks chosen before anyone writes the happy path.
Services
Third-Party Integrations
Two systems that disagree about the same order cost more than the hour someone spends re-keying it. We connect the ones you already run, and handle what happens when one goes down.
Somebody in finance exports a CSV every Monday morning because the ERP and the billing system have never spoken to each other. Somewhere else, a customer record exists twice with two different addresses, and nobody can say which one the warehouse will use. Integration work is mostly this: making systems that were never designed together agree on the same facts, in the same order, without a person in the middle keeping score.
How systems connect
Most integrations are one of four shapes
The right pattern depends on how fresh the data has to be, and on what the other end supports. Often the vendor's API decides for you.
Scheduled batch and files
Plenty of systems still trade flat files on a schedule, and that is often the correct answer. The overnight product feed, the payroll export, the SFTP drop a bank will not replace.
Events and messaging
One system publishes what happened; others react in their own time. It keeps the sender from waiting on the slowest consumer, at the cost of a queue you now have to watch.
What happens when it fails
Retries, idempotency keys, dead-letter queues, reconciliation jobs and alerts that name the broken link rather than the whole pipeline. This is the part that decides whether you trust the integration a year from now.
An integration is judged on its bad days
The happy path is the easy half. The real test is the afternoon the payment provider returns a timeout after it has already taken the money, or the CRM accepts a record and silently drops a field it does not recognise. Nobody notices silent loss until somebody downstream asks why a month of orders is missing a country code.
So we settle the awkward questions early: which system is the record of truth for each field, what makes a retry safe to repeat, how long a queue may back up before someone is woken. Then we build the reconciliation that proves both ends still agree, and the dashboard that shows it. At 3am the on-call engineer should not be guessing.
What the work runs on
Most of this is decided for you. The vendor at the far end supports what it supports, and your own platform already has a broker and an identity provider. We argue for a change only when the alternative keeps breaking.
- REST / JSON
- GraphQL
- Webhooks
- OAuth 2.0
- SFTP / EDI
- Apache Kafka
- RabbitMQ
- Azure Service Bus
- SAP
- Salesforce
- Dynamics 365
- Stripe
- OpenAPI
- Postman
How an integration gets built
Integration work fails in the gaps between teams more often than in the code. So the early steps are about writing down what each side promises, and the later ones about proving it still holds.
- 01
Map the flows
We list every place data crosses a boundary today, including the spreadsheets and the person who emails a report on Fridays. You get a diagram of the current flows with the system of record marked for each entity.
- 02
Agree the contract
Fields, formats, error codes, rate limits, what a retry means and who owns a record when both ends have edited it. This lands as an OpenAPI or schema document that your vendor's engineers can argue with before anyone builds.
- 03
Build against a harness
We stub the far end first, with the failures in it: timeouts, malformed payloads, a 500 halfway through a batch. The test harness stays in your repository, so the next change can be proved safe without calling a live vendor.
- 04
Run it in parallel
The new pipeline runs alongside the manual process while both are compared, so a disagreement shows up before it reaches a customer. You see the reconciliation report daily, and we cut over only when it stops finding differences.
- 05
Hand it over
Dashboards for throughput and lag, alerts that point at the failing hop, and a runbook covering the calls you will have to make when a vendor has an outage. Yours to operate, in your accounts, from the first commit.
Questions buyers ask
Ours, in practice. Working out what an API really does when the docs are wrong is a large part of the job, and we budget for it rather than treat it as a surprise. What we need from you is a contact at the vendor who can answer a question, because some behaviour cannot be discovered from the outside.
Not sure which one you need?
Describe the problem in a paragraph and we will tell you which service applies.