API integration in logistics: designing for partners you do not control

Choose by whether a decision is waiting

Interactive calls suit interactions where somebody or something cannot proceed until an answer arrives: rating a shipment, checking service availability at a postcode, reserving capacity, validating an address, producing a label. Scheduled exchange suits bulk state synchronisation such as overnight order files, daily stock positions or invoice batches. Applying the interactive pattern to bulk work produces thousands of calls that achieve what one file would, and applying the scheduled pattern to a waiting decision produces a customer staring at a pending screen.

Idempotency and duplicate side effects

Networks fail after a request is processed but before the response arrives, and the caller retries. In logistics that means duplicate bookings, duplicate labels, duplicate collections. The remedy is a client-supplied key that the receiving system treats as the identity of the operation, returning the original outcome on a repeat rather than performing it again. Any interface that creates a physical consequence needs this, and asking about it early is a reliable way to gauge how much production experience a partner's interface has behind it.

Throttling, retries and back pressure

Partner services limit how fast they will be called, and peak periods are exactly when both your volume and everybody else's rise. Clients need to respect published limits, back off progressively when refused, queue rather than fail user-visible work, and distinguish retriable failures from permanent ones. Without back pressure, a slow partner turns into a queue of blocked threads in your own application, and an unrelated part of the operation stops. Circuit breaking with a documented degraded behaviour is what keeps a partner outage local.

Push, poll and event ordering

Status updates can be polled or pushed to a callback endpoint. Polling is simple and wasteful; callbacks are efficient and require an endpoint you must secure, monitor and make tolerant of duplicates and out-of-order arrival. Delivery events genuinely do arrive out of sequence when devices synchronise late, so consuming systems must sequence on the event timestamp rather than on arrival, and must handle an event that contradicts a later state without corrupting the record.

Versioning, credentials and the partner estate

Over time an operator accumulates connections to many carriers, customers and platforms, each with its own authentication, versioning policy and change cadence. Credential expiry is a common cause of interfaces that silently stop; version deprecation announced by email to a departed colleague is another. Practical hygiene means an inventory of every partner connection with its owner, credential expiry, version in use and contact, plus synthetic checks that exercise each connection independently of business volume, so a failure is discovered before an operator reports it.

Frequently asked questions

Do interactive interfaces replace scheduled messaging?

In practice they coexist. Most operators run both for years, choosing per interaction, because replacing working bulk exchanges yields little while migrating decision-blocking interactions yields a lot.

What should be agreed with a partner before building?

Behaviour under failure and load, not just the field list. Specifically, retry expectations and idempotency, rate limits, how breaking changes are announced, sandbox availability with realistic data, and who is contacted when the interface degrades.

How is customer-facing data best exposed?

Through a stable interface of your own that hides which internal or partner system supplies each element. Exposing partner responses directly means every partner change becomes a change your customers experience.