A field-tested approach to integrating iDempiere with DHL Express, FedEx Ship, and UPS Developer Kit: rate shopping, one-click label generation, AWB tracking, pickup scheduling, and proof-of-delivery capture.
Grouped by the decision each section supports. Jump straight to the part you need.
Without ERP ↔ carrier integration, every shipment requires a warehouse operator to open the carrier portal, re-key the AWB details, download the label, paste it on the box, and then re-enter the tracking number back into the ERP. For a 200-shipment-a-day operation, that's 4–6 labor hours and a meaningful error rate.
A proper integration collapses the whole thing into a single click inside iDempiere: ship a package, print the label, book the pickup, and have the tracking number post back to the ERP automatically.
Every carrier API, whichever vendor, reduces to the same four calls. Get these right and the rest is mapping.
Weight, dimensions, origin and destination in; the services available on your account and their prices out.
Create the AWB and return a printable label, as PDF for a laser printer or ZPL straight to a thermal printer.
Book the collection window and close the day's manifest so the driver arrives against a known consignment list.
Ingest carrier events and move the iDempiere shipment through its status, ending in delivery with proof captured.
The four functions are the same everywhere. Authentication, payload shape and label handling are not, and that is where integration effort actually goes.
| Aspect | DHL Express | FedEx | UPS |
|---|---|---|---|
| Current API style | MyDHL API, REST / JSON | REST / JSON, modernised from the legacy SOAP stack | REST / JSON, after the SOAP XPCI stack was retired |
| Authentication | HTTP Basic with account number and API key | OAuth2 client credentials; token valid about an hour | OAuth2 client credentials |
| Token handling | None needed — credentials sent per call | Cache and refresh before expiry, or every call pays for a token | Cache and refresh before expiry |
| Label formats | PDF and ZPL, base64 encoded in the response | PDF, ZPL and thermal variants | PDF and ZPL |
| Bulk tracking | Per-AWB calls, or subscribe to tracking webhooks | Batched — multiple tracking numbers per call | Per-shipment lookup |
| Sandbox | Mirrors production structure | Separate credentials and host | Separate credentials and host |
| Usual integration effort | Lowest — simplest auth model | Moderate — token lifecycle to manage | Moderate — token lifecycle to manage |
Carrier APIs are versioned and do change. Treat this as an orientation to the shape of the work, and confirm the current contract against each carrier's developer portal before you scope a build.
DHL offers a modern MyDHL API with REST/JSON endpoints for rate shopping, shipment creation, label generation, pickup booking, and tracking. Key endpoints we use:
POST /rates — get a rate quote with service optionsPOST /shipments — create an AWB, returns the base64-encoded label (PDF or ZPL)POST /pickups — schedule pickup for the day's manifestGET /tracking/{awb} — pull status; or subscribe to tracking webhooks for push updatesAuth is HTTP Basic with your DHL account number + API key. Sandbox and production share the same structure. We cache rate quotes for 15 minutes to keep the UI snappy.
FedEx's REST API (modernized from the legacy SOAP stack) covers rating, shipping, tracking, and pickup. Auth uses OAuth2 client-credentials flow:
POST /oauth/token — client_id + client_secret → access token (valid 1 hour)POST /rate/v1/rates/quotes — rate shopping with all eligible servicesPOST /ship/v1/shipments — shipment creation; returns label (PDF, ZPL, or thermal) and tracking numberPOST /pickup/v1/pickups — close-of-day manifest and pickupPOST /track/v1/trackingnumbers — bulk tracking (up to 30 AWBs per call)UPS also offers modern REST endpoints after retiring the SOAP XPCI stack. We use:
/api/rating/v1/Rate — rate shopping/api/shipments/v1/ship — shipment + label/api/track/v1/details/{inquiryNumber} — tracking/api/shipments/v1/pickup — pickup schedulingFor every shippable iDempiere document we call all three carriers in parallel and rank the results. The operator picks a strategy rather than a carrier.
Lowest total landed cost regardless of transit time. Right for stock replenishment and anything where the customer has not been promised a date.
Shortest committed delivery date. Used for replacements, recovery shipments and anything already running late.
The lowest price that still hits the customer's required date. This is the one most operations should default to — it protects the promise and the margin at once.
Quotes are cached briefly per origin, destination, weight and service so the screen stays responsive without going stale. One click, and the chosen carrier's label is generated against the shipment.
The carrier returns a base64-encoded label (PDF for A4 printers, ZPL for thermal label printers like Zebra ZD420). We attach the label to the iDempiere M_InOut via C_Attachment and the AWB number goes into the shipment's tracking field.
Warehouse clients almost always prefer thermal printers on 4×6" labels. Plan for that hardware in your rollout and test a few hundred labels end-to-end before go-live — thermal printer quirks are real.
Each carrier publishes its own status vocabulary. We normalise all of them onto one internal state machine, so a report or a customer-facing screen never has to know which carrier moved the box.
The carrier has taken physical custody. Until this event fires, a printed label means nothing has actually shipped — a distinction that matters when a customer asks where their order is.
Movement between facilities. Useful mainly for exception detection: a consignment that has not moved for longer than its lane normally takes is worth a call before the customer makes one.
On the final vehicle. This is the event worth pushing to the customer, because it is the only one that tells them something actionable about today.
Receiver name and, where the carrier provides it, the signature image are captured and attached to the iDempiere shipment. That attachment is what settles a delivery dispute months later.
Address problem, failed attempt, customs hold or damage. Exceptions are the whole reason to ingest tracking at all — they are the events somebody has to act on.
Not every shipment goes through cleanly. Common exceptions:
We've shipped production integrations for 3PL operators, eCommerce exporters, and manufacturers. Typical turnaround is 3–5 weeks including testing.
A carrier integration is a small, well-bounded project. It should be quoted and run as one.
Which carriers, which services, which countries, and what your warehouse actually does today. Carrier credentials and a sandbox are the only prerequisites.
An OSGi plugin inside iDempiere plus a thin service layer, so the integration survives upgrades instead of being reapplied after each one.
Sandbox first, then a live pilot lane with real labels on real boxes. Printer behaviour and address edge cases only surface with physical shipments.
The plugin, the mappings and the documentation are handed over in your repositories, so a future change does not require us.
The questions that come up before every carrier project.
Six pages cover iDempiere here, each answering a different question — the practice, choosing a partner, what it costs, and the three integrations clients ask for most. Whichever you landed on, the rest are one click away.
Get a free Proof of Concept — we build a working iDempiere environment with your data, modules, and integrations in 2–3 weeks. Zero upfront cost, zero obligation.