API Development and Integrations

By who is calling and how many different shapes of data they need. REST is the default for anything external, because every integrator can read it, debug it with curl and cache it with standard tooling. GraphQL is worth its extra machinery when many clients need different slices of a connected object graph and the alternative is a growing pile of one-off endpoints — but you take on query cost limiting and caching yourself. gRPC is for internal service-to-service calls where both ends share a schema and the payload and latency savings matter. Plenty of systems run two of the three, with one documented as the public front door.

Usually yes, and it is a large part of what we do. We start by reading access logs and the existing client code to establish what is really depended on, then put the new surface alongside the old behaviour rather than replacing it. Where the internal data model is not fit to be exposed, the API gets its own representation layer so you are not committing to your current schema in public. The riskiest part is normally the authentication change, so that goes first, behind a flag, with the old path still working.

We have worked with the common categories — accounting and ERP systems, CRMs, HR and payroll platforms — and the approach is the same regardless of vendor: read the API docs and rate limits, build an adapter that translates their model into yours, decide field by field which system owns which data, and run the sync one-directionally where at all possible. The parts that need care are their rate limits, their pagination behaviour on large exports, and what happens when a record is deleted on one side. If the system only offers file-based exchange, we build around that rather than pretending it is an API.

Three mechanisms together. Idempotency keys on every charge request, so a retry returns the original outcome instead of creating a second transaction. A transactional outbox, so the database record and the outbound call cannot diverge if the process dies between them. And reconciliation against the provider as the source of truth, because a webhook you never received is otherwise invisible. Callbacks are signature-verified and deduplicated on the provider's event ID, and anything that moves money is confirmed against the provider's API rather than trusted from the payload.

Going down is the easier case: timeouts, bounded retries with backoff, a circuit breaker so we stop hammering them, a dead-letter queue for what could not be delivered, and a defined degraded behaviour for the user-facing flow. Changing is harder, because most vendors do not version well. The adapter layer contains the damage to one file, contract tests against their sandbox catch shape changes early, and we log every request and response to the vendor so a behaviour change can be evidenced rather than argued about.

Yes, generated from the spec rather than written separately, so they cannot drift from the implementation. That means an OpenAPI or protobuf document in your repository, rendered reference docs, examples drawn from the test fixtures, and generated clients in the languages your consumers use. For most APIs a well-maintained spec plus a working sandbox is more valuable to integrators than a hand-written SDK, so we start there and add SDKs when there is a consumer asking for one.

Real interactions with the sandbox are recorded once and replayed in the test suite, so CI runs fast and offline and does not depend on a sandbox being up. On top of that we run the failure cases the sandbox will not produce on demand — timeouts, malformed responses, duplicate callbacks, out-of-order callbacks — against a stub. A smaller set of tests does run against the live sandbox on a schedule, which is what catches the vendor changing something without telling anyone.