You want shipping in your app — the first fork is whether to integrate carriers directly or an aggregator's API. Direct gives control and fifteen maintenance burdens; aggregator gives one endpoint and a markup. For most builds, the answer is obvious.
The aggregator path
One REST API handles quote → book → label → track across the panel. Pakka Parcel's channel API works this way: POST an order, GET quotes across carriers, POST a booking, receive webhooks on status. The integration surface is four endpoints; the carriers' quirks live server-side.
The direct path
Each carrier has its own auth (token/OAuth/API key), its own quote shape, its own label format, its own webhook signature — Delhivery's API is genuinely good but you'll still write the Delhivery-shaped integration, then the Xpressbees-shaped one, then the Porter-shaped one. Direct makes sense past ~1,000 orders/day or when one carrier is 80% of volume.
The primitives that matter
Whatever API: quoting (rate+ETA per service), booking (creates AWB), labels (4×6 PDF), tracking (poll or webhook), and cancellation. An API missing any of these is incomplete; check the docs before committing.
Webhook hygiene
Verify signatures — carrier webhooks sign with HMAC; a webhook endpoint that trusts payloads blindly is a spoofable order-status injection. Store the raw payload for debugging; map to canonical statuses, not the carrier's quirky codes.
Pakka Parcel automates exactly this — the pipeline from order to AWB without the manual steps.
See how →The playbook
Choose aggregator vs direct
One integration vs fifteen — volume decides.
Integrate the four primitives
Quote → book → label → track — the complete loop.
Verify webhook signatures
HMAC verification is not optional.
Map to canonical statuses
'OFD' and 'out_for_delivery' and 'OFDL' are one status.
