Technology
IntegrationsAPIs, Webhooks, Bridges
The integration stack we reach for, the trade-offs we name, and when we use something else — typed APIs and webhooks as the default, the bridge layer as the architecture, the audit log as the requirement, with the choice made against the data, the team and the compliance posture.
What we use it for
Typed APIs and webhooks as the default — the right answer for the data flow between systems. The bridge layer as the architecture — the typed contract, the retries, the idempotency, the dead-letter queue. The audit log as the requirement — every action stamped with the user, the inputs, the outputs and the timestamp.
We extend the stack with the tools the integration needs — Kong, Apigee, AWS API Gateway, Tyk for the API management. The choice is made against the data, the team and the compliance posture.
When we choose it over the alternative
Typed APIs are right when the systems have an API, the contract is documented, and the team can build against the contract. Webhooks are right when the system emits events and the consumer can subscribe. The bridge layer is right when the integration is non-trivial, the retries are needed, and the audit log is the requirement.
The right answer depends on the data, the team and the compliance posture. We will say so on the call, with a written rationale for the choice and the trade-offs named.
When we do not choose it
We do not choose a managed API gateway when the workload is a single service and the gateway is over-engineering. We do not choose a custom bridge when the integration is a single script and the bridge is over-engineering. We do not choose the default when the cost (managed service pricing) makes the alternative the right answer.
Frequently asked
The questions the team asks
- How do you handle silent integration failures?
- Idempotency, retries with backoff, a dead-letter queue for messages that cannot be delivered, and monitoring that alerts when the queue is growing. The integration is part of the architecture, not a script, and the failure modes are named.
- What if the system has no API?
- We wrap it. A controlled export (CSV, SFTP, scheduled database dump) with a typed contract and a written SLA. The export is treated as a real integration, with monitoring and the same dead-letter handling. When the vendor ships an API, we move to it without breaking the consumer.
- How do you handle the API contract?
- A documented contract (OpenAPI for REST, GraphQL schema for GraphQL) as the source of truth. The contract is the artefact the consumer reads, the implementation is the code that satisfies the contract, and the contract is part of the architecture, not a wrapper.
Have a project in mind?Let’s scope it together.
Tell us the outcome you need. You get an approach, a rough timeline and next steps within one business day.