Question 1

Should we build point-to-point integrations or run an integration platform?

Accepted Answer

Point-to-point is the right answer far more often than vendors admit. Below roughly a dozen integrations, direct connections are cheaper to build, easier to debug and have no licence cost. An integration platform earns its keep when you have many systems, repeated patterns across them, and a team that will actually own the platform. We have seen more mid-market companies regret buying an iPaaS they never staffed than regret writing a dozen well-tested connectors.

Question 2

Our third-party API is unreliable. How do you handle that?

Accepted Answer

We assume every external dependency will fail and design for it: timeouts on every call, retries with exponential backoff and jitter, circuit breakers so one slow vendor cannot exhaust your connection pool, and idempotency keys so a retry cannot double-charge or double-ship. The failures then become queued work to replay rather than incidents, and your system degrades in a way your users can tolerate.

Question 3

Do you version APIs, and how do you handle breaking changes?

Accepted Answer

Yes. New fields are additive and never break existing consumers; genuinely breaking changes get a new version with both running in parallel and a published deprecation window. We instrument per-version usage so the decision to retire a version is based on who is actually calling it rather than on a guess. Consumer-driven contract tests catch a breaking change in CI rather than in someone else's production.

Question 4

How do you secure APIs that partners consume?

Accepted Answer

OAuth 2.0 or mTLS depending on the partner's capability, scoped tokens so a key can only do what it needs, rate limiting per client rather than globally, and full request logging with sensitive fields redacted. Every partner gets their own credentials so access can be revoked individually without a coordinated rotation across everyone.

Question 5

Can you work with our existing SOAP or file-based systems?

Accepted Answer

Regularly. A lot of enterprise integration still runs on SOAP, SFTP drops and fixed-width files, and replacing those systems is usually not on the table. We put a modern interface in front of them — a REST or event facade that handles the translation, retries and monitoring — so new work builds against something sane while the legacy system keeps running untouched.

Question 6

How long does a typical integration take?

Accepted Answer

A well-documented REST API with sandbox access is usually one to two weeks including tests and monitoring. A poorly documented legacy system, or one where the vendor requires a certification process, is four to eight weeks and most of that is waiting on the other party rather than writing code. We front-load the discovery on the vendor's side precisely because that is where the schedule risk sits.

Systems that actually talk.

What we actually deliver.

API design & delivery

Third-party integration

Events & messaging

Legacy facades

A sequence that de-risks delivery.

Map the actual contract

Design for failure first

Build with contract tests

Instrument and hand over

What clients measure afterwards.

Outages absorbed

No double-charges

Breaking changes caught

Integrations observable

Work we have actually delivered.

Migrated inboxes between providers with zero data loss.

Built an online CA platform that ranks for 300+ search terms.

Tools we work fluently in.

Senior engineers, accountable outcomes.

We probe the API before we estimate

Failure handling is not a phase two

We resist buying an iPaaS you won't staff

Every integration ships observable

Questions, answered.

Book an integration call - leave with the real risks.

Tell us about your project.