Connecting Shipping and Logistics Interfaces in 2026

An online shop can accept orders, but it is not a shipping system. As soon as a parcel physically sets off, entirely different data and services come into play: labels in a printable format, tracking numbers from the carrier, status events from its network and return-label workflows. These functions are provided by the carriers' APIs, and each speaks its own data format. For shoppers, shipping is no sideshow: according to Bitkom, shipping and delivery is a very important criterion in choosing an online shop for 53 percent (Bitkom) of customers.

Expectations around delivery are shifting. McKinsey reports that speed as a priority fell from first place in 2022 to fifth in 2024, and that cost is now the most important criterion when assessing deliveries (McKinsey). More than 95 percent (McKinsey) of respondents prefer free standard shipping over paid express shipping. For the shop this means: not the most expensive carrier, but the one that fits the shipment should be chosen automatically. This logic belongs in an upstream integration layer that mediates between shop and carrier and keeps the commercial rules central.

The market for software that delivers exactly this integration is growing accordingly. The global market for warehouse management systems was valued at USD 4.06 billion (SNS Insider) for 2024, with a projected annual growth rate in the double digits. Behind this figure stands a clear need: shipping, warehouse and returns should no longer run by hand but be system-supported. A well-designed integration into a Shopware CE shop maps exactly that, connecting the order to physical logistics without inflating the shop itself into a shipping system.

At its core, a carrier API provides three functional areas that map the lifecycle of a shipment. The first is label generation: from the recipient address, weight, dimensions and chosen product, the carrier generates a shipping label, usually as PDF or ZPL for label printers, together with a unique tracking number. The second is tracking: the carrier reports status events such as picked up, out for delivery or delivered. The third is returns: a return label with which the customer can send goods back, plus the information on when they arrive again. Modern carriers provide these functions via REST interfaces in JSON format.

Each carrier fills these functions differently. Product codes, mandatory fields, weight units and the structure of address data differ from provider to provider. A shipment with one carrier is addressed differently than with another, and a return label follows its own flow at each provider. This is precisely why every integration needs a mapping between the internal shipping model and the respective carrier format. How to design such an internal model cleanly is explored in depth in the article on the product data pipeline of PIM integration, because the principles for master data also apply to shipping data.

Those who connect only one shipping provider make themselves dependent on its rates, transit times and availability. In practice, most shops therefore run a multi-carrier strategy: standard parcels via the cheapest provider, heavy or bulky shipments via a specialist, international shipments via a carrier with a good overseas network. The shipping middleware selects the fitting provider per shipment by rule. This decision depends on weight, destination country, requested date and cost, and should be centrally configurable rather than scattered across shop code.

The effort of a multi-carrier integration lies in the mapping per provider, the benefit in flexibility and cost control. Since cost is today the most important criterion for shoppers and more than 95 percent (McKinsey) prefer free standard shipping, a smart rate choice pays off directly: every cent saved per shipment improves the margin or allows shipping to be kept cheaper for the customer. A shipping middleware encapsulates the carriers behind a uniform internal interface, so that a new provider becomes a configuration rather than a rebuild of half the shop. How such a middleware differs fundamentally from a pure point-to-point integration is examined in the design of the interface architecture.

As soon as a shipment is on its way, the customer wants to know where it stands. The desire for transparency is clear: according to DispatchTrack, 90 percent (DispatchTrack) of customers want to track their deliveries, and a consumer survey by Sifted names real-time tracking as critical to a positive delivery experience for 88 percent (Sifted) of respondents. Technically there are two ways to obtain the status events: the middleware polls the carrier at intervals, or the carrier actively reports each status change via webhook. The difference is substantial -- in load, timeliness and cleanliness of the architecture.

A webhook is an HTTP call that the carrier sends to an agreed endpoint of the middleware as soon as something changes. This is more efficient than regular polling because no empty queries occur and the status is available almost in real time. The downside: the endpoint must be reachable, secured and idempotent, because a carrier can send the same event more than once. Which approach fits better when, and how to combine both methods robustly, is explored in depth in the article comparing webhooks and polling.

The example shows the core of a tracking event: an event type, the tracking number, the new status, a timestamp and a reference to the original order. The middleware receives this event, assigns it to the correct order via the order reference and updates the shipment state in shop and ERP. Idempotency is important: if the same event arrives twice, it must not confuse the status or trigger a duplicate notification. A state machine that allows only permitted transitions prevents a delayed message from marking an already-delivered order as in transit again.

Returns are not an exception in online retail but everyday business. According to the EHI Retail Institute, in Germany almost every fourth online parcel comes back fully or partially, and 28 percent (EHI Retail Institute) of online retailers receive more than every fourth item sold back. In the fashion segment the rate is considerably higher. These volumes cannot be handled by hand. A return runs through its own lifecycle: the customer registers the return, receives a return label, the parcel arrives at the warehouse, is checked and finally triggers a credit note. Each of these steps is a data event that must flow through the systems.

The key to a robust returns process is the unique link between return, original order and credit note. If this reference is lost, a parcel ends up in the warehouse without assignment and must be researched by hand -- exactly the manual effort that automation is meant to avoid. Bitkom also points out that an overly complicated return deters customers: around half of online shoppers keep products because the return seems too complicated (Bitkom). A smooth returns process is therefore not only logistics but part of customer loyalty. The error handling involved -- such as missing references or aborted cases -- follows the same principles as any other secured interface.

Shipping and warehouse are inseparably linked. Before a label is generated, it must be clear that the goods are available; as soon as they leave the warehouse, stock must fall; when a return comes back, it must rise again. This synchronization between shop, ERP and warehouse or fulfillment system is the backbone of a robust shipping process. The economic lever is measurable: modern warehouse management systems raise picking accuracy from around 85 percent to up to 99.8 percent (SNS Insider), because they guide stock, pick list and package in a system-supported way rather than by word of mouth.

With external fulfillment, for example through a logistics provider, another interface is added: orders go to the provider, shipping and stock notifications come back. The same applies here as for carrier integration -- an internal model in the middle, partner-specific profiles at the edges. Coupling to the ERP that runs stock and accounting happens via its REST or GraphQL API and follows the same patterns as a SAP integration. It is important that stock movements are processed idempotently: a duplicately reported issue must not reduce stock twice. Exactly this diligence distinguishes a robust integration from a fragile makeshift solution.

A robust shipping integration places all the logic in a middleware between shop and carriers, not in the shop. This layer receives the shipping request, selects the carrier, generates the label, persists every shipment with a unique reference and processes tracking events asynchronously. The advantage of this decoupling is robustness: if a carrier API briefly fails, the shipping request remains safely in the queue and is retried without the customer noticing. In our experience, integration projects fail above average not because of business logic but because of non-functional requirements such as load behavior and fault tolerance (project experience).

Persistence with a unique reference is central here. It ensures that no shipping request is lost and no shipment is created twice, even if a call has to be retried. Decoupling also makes it possible to separate fast acceptance from the actual processing: the shop receives an immediate confirmation, while label generation and carrier mapping run in the background. These principles apply equally to shipping and to EDI exchange with trading partners, which the sister article on EDI integration with EDIFACT covers in depth. Across more than 50 integration projects (project experience), this clean separation has proven considerably easier to maintain than shipping logic scattered across the shop.

Economically the effort pays off because shipment volumes keep growing. The German CEP market generated around EUR 27.6 billion (BIEK CEP Study) in revenue in 2024 and employed about 266,300 (BIEK CEP Study) people in the parcel industry alone. Every shipment in this market needs a label, a status and, in case of doubt, a return. Those who automate these processes scale without proportionally growing staff. An accompanying integration consultation helps align the integration to your specific carriers, volumes and processes, rather than imposing a standard solution that does not fit your shipment types.