A clear, honest walkthrough of the moving parts behind ERPNext courier integration: the native Shipment document, the three ways couriers plug in, and how automated AWB generation, live shipment tracking, bulk label printing and COD reconciliation really run. Written for teams choosing between a multi-courier aggregator and a custom courier API integration.
Courier Integrations
Live Tracking Updates
AWB Allocation Accuracy
Everything in ERPNext shipping sits on one core object, and it is native to ERPNext out of the box. The Shipment document records a real-world consignment created against a Delivery Note or on its own, and it holds the fields your operations team cares about: the AWB number, the carrier, the shipment status, parcel dimensions, and the pickup and delivery addresses.
Because that document is standard, the data model for shipping is always present. The natural flow of a dispatch is Sales Order, then Delivery Note, then Shipment, and the AWB and live status live on that Shipment record for the whole team to read. What changes from one client to the next is the connector that fills the Shipment with a real AWB from a courier and keeps its status current.
How ERPNext structures your fulfillment workflow with native documents, connectors, and real-time return data loops.
Order is confirmed inside ERPNext from any channel.
Goods are picked and packed, ready to ship.
Holds AWB, carrier, status, parcel and addresses.
Aggregator or custom API books the AWB with the courier.
Parcel is collected and moves through the network.
← Flows back: tracking status and delivery events return into the Shipment document, and COD collected feeds the accounting reconciliation.
This is the part that decides your effort and cost. There are three genuinely different paths, and the couriers most Indian businesses use spread across all three.
The official ERPNext Shipping app handles shipment creation, rate comparison, label printing from the Shipment document and tracking. Its built-in providers are European aggregators, so on their own they often do not serve Indian lanes.
The common route in India. One connector covers many couriers, with rule-based allocation that picks the courier by serviceability, SLA or cost, and pushes live status straight into the Shipment document.
A custom Frappe app that books directly with one carrier's API. More build effort, no middleware fee, and full control of the flow. Well proven for couriers like Delhivery, Blue Dart, FedEx and DTDC.
A closer look at dispatch events, status triggers, and the accounting boundaries behind logistics.
Scope it as an accounting and reporting deliverable, usually a custom report fed by courier remittance data, not something that arrives free with the courier connector.
The most defensible line for an Indian client - none of these five are plug-and-play native connectors in core ERPNext. Each arrives through an aggregator or a custom app on the courier API. The native piece is the Shipment document and its AWB, status, label and tracking behaviour through whichever connector you install.
| Courier | Typical route in ERPNext | AWB & label | Tracking | COD |
|---|---|---|---|---|
| SRShiprocket | Aggregator connector | Yes | Live | Supported |
| DLDelhivery | Aggregator or custom app | Yes | Live | Supported |
| BDBlue Dart | Aggregator or custom API app | Yes | Live | Configurable |
| FXFedEx | Custom API app or aggregator | Yes | Live | Lane dependent |
| DHDHL | Custom API app or aggregator | Yes | Live | Lane dependent |
The Shipment document, AWB and status fields, label printing and tracking are native. The courier connection is added through an aggregator or a custom Frappe app on the courier API.
A clean three-tier framing lands better with an operations buyer than a flat claim of covering every courier.
Cost: platform fee
Fastest to stand up and covers many couriers at once, with a per-shipment or subscription platform cost to factor in.
Cost: no middleware
Higher build effort per courier but no middleware fee and full control of allocation, labels and tracking behaviour.
Accounting item
A distinct accounting and reporting deliverable, estimated on its own rather than bundled into the courier connector.
ERPNext shipping and logistics integration FAQ
The Shipment document is native and stores the AWB number, carrier, status and parcel details, and it is created from a Delivery Note or on its own. The courier connector that generates the AWB and syncs tracking is added on top through the official shipping app, a multi-courier aggregator, or a custom API app.
From a Delivery Note you create a Shipment, then the connector calls the courier or aggregator API, allocates the AWB and writes it back onto the Shipment along with the label and tracking link, so nobody logs into a courier portal.
An aggregator like Shiprocket or eShipz is the fastest and covers many couriers through one connector with rule-based allocation at a platform cost. A custom Frappe app books directly with one courier API, which needs more build effort but removes the middleware fee and gives full control. Many businesses mix both.
COD reconciliation is an accounting workflow rather than a shipping connector feature. It matches COD collected by each courier against the remittance to your bank and the COD invoices and is usually delivered as a report or reconciliation process scoped separately.
Yes. Any courier with an API can be connected through a custom Frappe app using Frappe's open REST API and webhooks, writing the AWB and status back onto the standard Shipment document.
Connect Delhivery, Shiprocket, Blue Dart, or FedEx with ERPNext. Automate AWB generation, print bulk shipping labels, and track shipments in real time.