Shipping API Integration: Multi-Carrier Rates, Labels and Tracking

A shared shipping interface for carrier rates, label purchases and parcel updates.

This shipping API integration case study puts one common interface in front of several different carriers. It compares carrier rates, buys labels and follows parcels in transit. The client reaches its connected carrier accounts through a dashboard or an API. Connectors translate each carrier's own requests and responses.

A single shipment record carries the parcel details all the way through the process.

The challenge

Carrier responses do not all carry the same fields. A purchased label may add a tracking identifier yet leave out parcel fields the client already supplied. Saving that label must not wipe the earlier details. Purchase and tracking also need separate handling. A label can be bought while the follow-up tracker still fails to appear.

What we built

Rate requests call the suitable connections at the same time. Live quotes and stored rate sheets land in one comparison, with configured markups and fees applied. A purchase checks access and shipment state, resolves the chosen rate and connection, then asks for the label. A shipment already marked as created is turned away by this path. Scheduled jobs collect the later tracking updates, and webhooks notify any connected apps that need them.

Technical approach

Carrier connectors keep request mapping, response parsing and HTTP transport apart. Mapping tests can run without a live carrier call. Package metadata registers the supported methods. Pickups, manifests and other operations stay available only where a connector implements them.

Preserve the shipment through purchase

The carrier response is merged into the existing shipment and its parcels. A narrower response can add identifiers without replacing the parcel's recorded weight or its other retained fields. The merged purchase is saved before tracker creation and the related document work begin. Those steps can fail on their own. Request and response traces sit with the saved shipment. Together they let an operator look into missing tracking after a purchase has gone through.

REST and GraphQL expose the stored shipments. A stateless proxy is there as well when the surrounding application already owns its shipment records.

Webhook delivery counts the failures and can switch off a subscription after repeated misses. Operators must watch and restore those subscriptions. Organisation isolation and carrier-credential encryption also call for deliberate deployment controls at setup. The shared connector model does not supply those guarantees by itself.

Project success

A chosen rate leads to a purchased label on the same shipment record, with its original parcel context kept. Later tracking runs on its own path and leaves its own failure evidence. Staff can look into an unfinished follow-up without mistaking it for a failed label purchase. The order application keeps using the shared shipping model.

Technology stack

Application

Python, Django

APIs

Django REST Framework, Strawberry GraphQL

Database

PostgreSQL

Background jobs

Huey, Redis

Dashboard

Next.js, React

Connector loading

Python packages and entry points