Where API integration fits on a long engagement.

The happy path is a small fraction of the work. What determines whether an integration is reliable is the handling of rate limits, partial failures, timeouts, inconsistent error formats and the provider's occasional undocumented behaviour change.

Rate limiting is the most commonly mishandled. An integration hitting a limit and retrying immediately makes the problem worse, and the correct behaviour — respecting the retry-after header, backing off exponentially, queueing rather than dropping — has to be built rather than assumed.

What an assigned team does with API integration.

Third-party APIs change without notice. A field deprecated, an error format altered, a rate limit tightened — none of which arrive as a notification to whoever built the integration.

Monitoring for behavioural change rather than only for outright failure is what catches those early, and it is part of what assigned capacity is responsible for under software development outsourcing.

What we use API integration for.

  • Rate limits respected properly Backoff and queueing rather than retrying into a limit.
  • Partial failure handled Batch operations where some items succeed, reconciled rather than retried wholesale.
  • Provider changes detected Monitoring for altered behaviour, not only for outright errors.

How API integration capacity is assigned.

Integration capacity is assigned inside the discipline that owns the consuming service, with provider change monitoring treated as part of the work.

Tell us what your roadmap needs API integration for.

A service delivery manager replies with the disciplines we would assign, the monthly capacity and what the first month looks like.

Loading the contact form… You can also email hello@azendo.co.

We reply within one working day. No obligation, and no newsletter.