How ERPNext shipping and logistics integration actually works

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.

350+

Courier Integrations

Real-time

Live Tracking Updates

99.9%

AWB Allocation Accuracy

Shipment document

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.

The key distinction: the Shipment document, its AWB and status fields, plus label printing and tracking are the native part. Booking with a specific courier is what the connector layer adds on top.

Architecture: From Sales Order to doorstep

How ERPNext structures your fulfillment workflow with native documents, connectors, and real-time return data loops.

STEP 1

Sales Order

Order is confirmed inside ERPNext from any channel.

STEP 2

Delivery Note

Goods are picked and packed, ready to ship.

NATIVE

Shipment doc

Holds AWB, carrier, status, parcel and addresses.

STEP 3

Connector

Aggregator or custom API books the AWB with the courier.

STEP 4

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.

Three ways couriers actually plug in

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.

Path 1 · Official App

Frappe shipping app

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.

Providers: LetMeShip, Packlink, SendCloud
Path 2 · Aggregator

Multi-courier aggregator

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.

Examples: Shiprocket, Shipz, 200+ couriers
Path 3 · Custom API

Direct courier API app

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.

Direct to: Delhivery, Blue Dart, FedEx, DHL, DTDC

The four workflows, and how each really runs

A closer look at dispatch events, status triggers, and the accounting boundaries behind logistics.

1

Automated AWB generation

From the Delivery Note you create a Shipment. 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. With an aggregator, the smart part is allocation: the right courier is chosen automatically by pincode serviceability, SLA or cost, rather than a person picking manually.

2

Live shipment tracking

The connector either polls the courier or receives webhooks and then updates the Shipment status on its own. Aggregators push status changes directly into the Shipment document, which is what lets support and customers see live movement from pickup to delivered without anyone logging into a courier portal.

3

Label printing

The label is generated by the connector and printed from the Shipment document. Single label printing is straightforward. True bulk or batch printing across mixed couriers is usually an aggregator feature or a small custom addition rather than something in the bare core, so it is worth confirming per courier.

4

COD reconciliation

This is the one to be precise about. COD reconciliation is an accounting workflow, not a courier connector feature. It lives in ERPNext accounts, matching the COD each courier collected against what they remitted to your bank and against the COD invoices and payment entries.

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 Honest Matrix: Native vs Aggregator vs Custom API

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.

CourierTypical route in ERPNextAWB & labelTrackingCOD
SRShiprocketAggregator connectorYesLiveSupported
DLDelhiveryAggregator or custom appYesLiveSupported
BDBlue DartAggregator or custom API appYesLiveConfigurable
FXFedExCustom API app or aggregatorYesLiveLane dependent
DHDHLCustom API app or aggregatorYesLiveLane 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.

How to scope a courier integration

A clean three-tier framing lands better with an operations buyer than a flat claim of covering every courier.

Aggregator Route

Effort: low

Cost: platform fee

Fastest to stand up and covers many couriers at once, with a per-shipment or subscription platform cost to factor in.

Custom API Route

Effort: higher

Cost: no middleware

Higher build effort per courier but no middleware fee and full control of allocation, labels and tracking behaviour.

COD Reconciliation

Effort: separate

Accounting item

A distinct accounting and reporting deliverable, estimated on its own rather than bundled into the courier connector.

Frequently Asked Questions

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.

Ready to automate yourShipping & Logistics?

Connect Delhivery, Shiprocket, Blue Dart, or FedEx with ERPNext. Automate AWB generation, print bulk shipping labels, and track shipments in real time.