Shipping Label and Carrier API

The shipping label is the visible result of digital shipping processing – and the carrier API is the technical interface that automatically generates the label, tracking number, and tracking data. In modern e-commerce fulfillment, the quality of this connection determines whether parcels leave the warehouse quickly, correctly franked, and with complete shipment tracking. Errors at this stage cost time, money, and customer trust.

This glossary entry explains the structure and function of shipping labels, how carrier APIs are integrated into the fulfillment stack, which data must be transmitted, and how to avoid typical integration errors.

What is a shipping label?

A shipping label is a machine-readable label affixed to a parcel that contains all the information carriers need for acceptance, sorting, transport, and delivery. It connects the physical parcel with the digital order.

Typical components of a shipping label:

• Recipient address – complete, routing-coded, and legible
• Sender address – mandatory for returns and claims
• Tracking number – unique tracking ID of the carrier
• Barcode or QR code – for automatic scans in sorting centers
• Postage information – product, tariff, and payment status
• Weight and dimensions – relevant for volumetric tariffs
• Additional services – e.g. cash on delivery, insurance, parcel locker

The label is typically delivered as a PDF or in printer format ZPL/EPL to a thermal printer. It is not created manually, but via shipping software, WMS, or directly through a carrier API.

What is a carrier API?

A carrier API (Application Programming Interface) is the programmatic interface of a shipping service provider through which external systems can create shipments, retrieve labels, cancel shipments, and query tracking events. Instead of generating labels manually in the carrier portal, your WMS or shipping software transmits structured data via HTTP request and receives the label file, tracking number, and status in return.

Core functions of a carrier API in fulfillment:

1. Shipment Create – create shipment with address, weight, product, and references
2. Label Retrieve – generate and return PDF or print format
3. Rate Shopping – query available tariffs and prices for shipment data
4. Tracking Pull/Push – retrieve status events or receive them via webhook
5. Cancel/Void – cancel unshipped labels and credit postage
6. Pickup/Manifest – book pickup or submit end-of-day manifest

The API does not replace the physical shipping process, but automates preparation: Correct postage and franking are determined at the time of label creation and booked with the carrier.

Process flow: From order to shipping label

Difference: Manual label vs. API label

Typical API data fields for label creation

Before a carrier generates a label, mandatory fields must be transmitted completely and correctly. The exact field names differ by carrier, but the business logic is similar.

Sender and recipient

• Name, street, house number, postal code, city, country
• Phone or email for delivery instructions (carrier-dependent)
• Parcel locker or branch ID for pickup services
• Reference number (order number, internal shipment ID)

Shipment data

• Weight in kilograms (actual or volumetric)
• Dimensions length × width × height in centimeters
• Shipping product (e.g. DHL Parcel, small parcel, merchandise mail)
• Goods value and currency (for insurance and customs)
• Number of parcels for multi-colli shipments

Optional additional services

• Cash on delivery (COD amount)
• Transport insurance
• Age verification, identity check
• Carbon-neutral shipping or GoGreen option
• Return label as enclosure

Carrier API in the fulfillment stack

In a typical fulfillment setup, the carrier integration sits between WMS, shipping software, and the physical packing process at the label printer shipping station.

Involved systems

The Transport Management System (TMS) often handles intelligent carrier selection: It compares tariffs, considers cut-off and shipping windows, and calls the appropriate carrier API.

Workflow: API label in the packing process

Multi-carrier and API abstraction

Growing shops rarely work with just one carrier. A multi-carrier strategy requires either multiple direct API integrations or shipping software as an abstraction layer that unifies different carrier protocols.

Advantages of centralized shipping software:

• One label printing workflow for DHL, DPD, GLS, UPS, and others
• Uniform address validation and error handling
• Centralized reporting on shipping costs and delivery rates
• Faster carrier switching without WMS rebuild

Disadvantages of direct individual integration:

• Higher development effort per carrier
• Different authentication (API key, OAuth, certificates)
• Inconsistent error codes and cancellation rules
• Maintenance during tariff and API version updates

Label formats and printing requirements

Carrier APIs typically deliver labels in these formats:

• PDF – universal, good for desktop printers and manual reprints
• ZPL (Zebra) – standard on thermal printers in fulfillment centers
• EPL – older Eltron format, still used on legacy hardware
• PNG – less common, for special printing stations

Important printing parameters:

• Resolution 203 or 300 dpi depending on printer
• Label size 100 × 150 mm or 102 × 199 mm (carrier-dependent)
• Separate formats for return labels or enclosures

Faulty printing – wrong format, insufficient contrast – makes even a correct API label unusable. Label creation is only complete when the barcode is scannable at the packing station.

Tracking and feedback after label creation

With the API response, you typically receive:

• Tracking number – basis for tracking number and tracking
• Tracking URL – direct link to carrier portal
• Label reference – internal carrier ID for cancellation and claims

Best practice in fulfillment:

1. Store tracking number in WMS immediately
2. Separate shipping status "label_created" from "shipped"
3. Send shipping confirmation only after successful label print and scan
4. Mirror tracking events into OMS via webhook or polling
5. Automate customer notification with tracking link

Common errors with shipping labels and carrier APIs

Technical errors

• Expired API tokens or missing OAuth renewal
• Timeout during high shipment volume (peak season)
• Wrong sandbox/production environment
• Encoding issues with special characters in addresses
• Missing idempotency – duplicate labels on retry

Business errors

• Weight from shop instead of actual packed weight
• Wrong shipping product despite correct API response
• Parcel locker without correct post number
• International shipments without customs data
• Label printed but shipment not in daily manifest

Process errors

• Label created, parcel never handed over (empty franking)
• Cancellation in WMS forgotten after API void
• Return label confused with outbound label
• Multiple labels on one parcel (double shipment)

Frequently asked questions

1. Do I need a separate API for each carrier? – Either directly or via multi-carrier software
2. When is postage charged? – Usually at label creation, not at delivery
3. Can I change a label afterwards? – No, cancellation and re-creation required
4. What happens during API outage? – Define fallback process (manual portal, retry queue)
5. How do I test the integration? – Sandbox with test addresses before going live

Checklist: Setting up carrier API for production

• Business customer contract with API access concluded with carrier
• Sandbox/test environment successfully completed with sample shipments
• API credentials securely stored in config/secret store (not in source code)
• Address validation and postal code logic implemented before API call
• Tariff mapping (shop shipping method → carrier product code) documented
• Label printer configured with correct format (PDF/ZPL)
• Tracking number write-back to WMS and shop tested
• Cancellation/void process defined for unshipped parcels
• Error monitoring and alerting for API outages set up
• Packing station staff trained on fallback process

Best practices for smooth label processes

1. Measure weight and dimensions at packing station – Never send only theoretical product weights to the API. A scale with automatic transfer to shipping software prevents under- and over-franking.
2. Automate carrier selection with rules – Rules by destination country, weight, cut-off, and service level reduce manual decisions and speed up the packing station.
3. Link label and packing slip – Scanning the packing slip before label print ensures the right label goes on the right parcel.
4. Log API responses – Store request ID, tracking number, and timestamp for claims and audits – without unnecessarily duplicating personal data.
5. Regular API version checks – Carriers update interfaces. Subscribe to release notes and run tests before production changes.
6. Load-test peak volume in advance – Black Friday and Christmas put more strain on APIs than everyday operations. Know rate limits and retry strategies beforehand.

Carrier API integration models compared

Related topics

• Tracking number and tracking
• Postage and franking
• Cut-off and shipping windows
• Carrier integration in shipping software
• Label printer and shipping station

Last updated: July 6, 2026