Magento Shipping Carrier Integration: Labels, Tracking Numbers and Tracking Directly From the Shop

A shipment consists of several steps: the order becomes ready to ship, a label is created, the parcel is handed over or picked up, and the customer receives a tracking number with tracking. Magento brings basic functions for this, such as shipping methods and shipments with tracking numbers. The connection to the shipping carrier that creates labels and reports status back is, depending on the provider, a task of its own.

A Magento shipping carrier integration takes exactly this work off you. A label arises from the order at the push of a button or automatically, the tracking number is written into the shipment, the customer receives the shipping confirmation with tracking, and the status can be retrieved in the shop. For returns a return label arises that the customer can retrieve himself.

Most providers require a business customer contract or access data issued by the provider for their interfaces. That means: without a contract no interface. The Magento shipping carrier integration therefore begins with the question with which providers you have contracts and which access you already have.

It is also important how your warehouse works: labels often go to thermal printers in certain formats, several parcels per order need their own labels, and some businesses print collective orders. We set up the integration as your warehouse works instead of adapting your processes to the interface.

Which data flows in the Magento shipping carrier integration you define with us in the inventory. Typically there are five areas.

Not every Magento shipping carrier integration project needs all five areas. Often it begins with labels and tracking numbers for one provider and later grows by returns and further providers. This way you see results quickly and can use the budget in stages.

The table shows a typical pattern. In your business it may differ, and that is exactly what we clarify in the inventory.

With the Magento shipping carrier integration a clear rule on responsibility prevents most disputes: the shop knows order, recipient and shipping method, the provider creates label and tracking number, and the log shows what was handed over. Weight and dimensions of the products must be maintained in the shop because without them the provider cannot calculate a label or a price.

For the Magento shipping carrier integration, DHL provides through its developer portal several interfaces for parcel shipping, including for creating labels, for pickups, for return labels, for tracking, for searching pickup stations and for checking locker details. Access requires a business customer contract, and according to the vendor there is no interface for private senders. With ShipIT GLS offers interfaces in the forms REST and SOAP through which shipments are created, labels retrieved as PDF, image or in a printer format and shipments tracked. Access data and addresses come from GLS, and further services such as price calculation, routing check and pickup orders belong to the offer.

According to several sources UPS provides an interface based on the REST principle with login through OAuth 2.0, with a test environment and a production environment, and names services for creating shipments and labels, for tracking and for cancelling. These statements partly come from third-party sources and must be checked at the developer portal of UPS before a project. With DPD and Hermes we did not find a publicly available, complete developer documentation. For both it applies: the Magento shipping carrier integration requires business customer access, and we clarify the details with the provider before we make a quote.

We deliberately do not work on assumptions in a Magento shipping carrier integration because interfaces, formats and terms change. That is an honest part of our approach: before the quote we check for every provider which interface your contract allows, and tell you openly if a way sets limits or causes additional costs.

There are three ways for the integration. The first is a ready-made module for a single provider, the second a service that bundles several providers and offers the shop a single connection. The third is an individual development directly against the interfaces of the providers. Whether an existing way covers your requirements we check honestly before a decision, and it is often the more economical choice.

For a Magento shipping carrier integration, a service that bundles several providers saves effort with many providers but brings an additional dependency and running costs. A direct Magento shipping carrier integration pays off with one or two providers with high shipment volume or with special rules, for example shipping method by weight and destination, bulky goods or freight forwarding. It is more expensive at the start but fits exactly.

If more than two systems are connected, for example shop, merchandise management, fulfillment and shipping carrier, a middleware can make sense. The decision aid is in the guide to ERP integration.

On the Magento side we build the integration as its own module according to the standards of the system, without interventions in the core. The module uses the interfaces and queues of Magento so that transfers run in the background and the shop does not become slower for visitors. Orders are placed in a queue on arrival and processed there until the ERP has confirmed them.

Magento maps shipping methods, weights, dimensions and addresses with its own functions, and these are exactly the data the shipping carriers need for labels. Where possible we use the standard functions of Magento instead of inventing our own tables. That keeps the shop update-capable and lets other developers join in later.

In the admin you see what was transferred: a log shows date, record and result, with a filter for errors. For the peculiarities of the carriers we add settings in the admin, for example assignments of payment methods, shipping methods and tax classes, so that changes need no development.

With shipping the moment matters. The Magento shipping carrier integration creates label and tracking number only when the order is ready to ship and writes the tracking number into the shipment so that shipping confirmation and tracking for customers arise automatically.

We see these points again and again in Magento shipping carrier integration projects. They can be planned if they are known early.

• No contract or access

  Business customer contract or access data for the interface are missing, and the project stands still.

• Missing product data

  Weight and dimensions are not maintained, and labels or prices cannot be calculated.

• Addresses

  Street and house number, address additions and pickup stations are handed over wrongly and the label fails.

• Several parcels

  An order goes in several parcels or partial deliveries, and tracking numbers are mixed up.

• Foreign shipping

  Customs details or special services are missing in the concept.

• Printer format

  The label appears in the wrong format for the thermal printer in the warehouse.

An integration connects two systems with business data, so clear rules apply. The exchange runs encrypted, credentials do not lie in the source code but in the protected configuration, and the integration receives only the rights it needs. Access belongs to a separate service account, never to a private account of a person.

When testing we work with test data or anonymized data as far as possible. As soon as developers get access to personal data, for example customer accounts or orders from the shop and the carriers, an agreement on commissioned data processing is needed. We clarify that before the start so that you are legally well set up.

The log of the integration contains what is necessary for operation but no credentials and no unnecessary personal data. Retention periods are defined with you. These notes are not legal advice, the concrete arrangement depends on your company.

We keep the start deliberately short so that you quickly know whether and how the integration is feasible.

The following constellations are examples from the practice of Magento shipping carrier integration projects, not statements about particular customers. The first is a small merchant who uses one provider and has so far created labels in the portal of the provider. Here the label will arise directly from the order in future, and the tracking number goes to the customer automatically.

The second constellation is a merchant with two providers, for example one for standard parcels and one for express or abroad. The challenge lies in the rule which order goes to which provider and in separate labels and tracking. We map the rule in the shipping methods of the shop.

The third constellation is a business with bulky goods and freight forwarding besides parcels. Here prices, dates and papers differ, and the integration has to deal with more details. We clarify early what the provider demands for this and build only what your contract also allows.

In all three cases a small trial pays off: before the integration runs productively, test shipments are created in the test environment of the provider, including a parcel with several packages, a foreign shipment and a return label. Your warehouse checks label and print, and only then does operation start. This way errors show up early and cost little.

An interface is not a one-off project but ongoing operation. After the start a log monitors every transfer: what was transferred when, what failed, what is repeated? Errors that cannot be fixed automatically are reported visibly so that nobody learns of them only through a customer complaint.

Updates change the situation. A Magento update, a new state at the carriers or a change of the vendor interface can affect the integration. Therefore the planning includes an agreement on how updates are tested and who approves them. Ongoing care can be regulated through a maintenance contract that covers monitoring, updates and error fixing.

Documentation is part of the delivery. You receive a description of the data flows, the assignments and the rules for special cases so that your team or another provider understands the integration and can continue it. Source code and access stay with you.

A flat figure for Magento shipping carrier integration would be unreliable because the effort depends on your constellation. It is determined by the number of data flows, the quality of the data in the systems of the carriers, the number of special cases with foreign shipping, multi-parcel shipments and returns and the required timeliness. A data flow in one direction is built much faster than a synchronization in both directions with conflict rules.

We work with an open hourly rate of 30 euros net, without emergency surcharge. After the inventory you receive a written estimate that lists the data flows individually so that you can control scope and order yourself. For clearly defined packages a fixed price is also possible. All prices are on the page pricing.

Besides the development, include the running items: hosting, maintenance and, where applicable, licenses or fees for the carriers and for additional services. We show these items separately in the estimate so that you can compare quotes over several years.

An honest offer includes naming the limits. We do not sell a ready-made connector off the shelf but develop Magento shipping carrier integration project by project according to your processes. That means: we implement exactly what you need, but not in a day and not for a flat price that cannot be calculated beforehand.

We are a web agency in which fixed freelancers work together, all from home offices. We are not a large agency with a hundred employees and cannot take on every project at every time. We tell you early whether and when we have capacity. We name customers only with their consent, and in the first conversation we gladly talk about comparable constellations.

We give no legal advice. Questions about commissioned data processing, data protection and the license terms of the carriers you clarify with your legal adviser and the vendor. What is technically possible depends on version, operation and license of your system and is checked in the inventory.