Custom multicarrier shipping software development
Those who ship with more than one carrier usually make the choice by hand or let a shipping platform choose. As volume grows, this starts to chafe: one destination can only be served by one carrier, one product may only go with another, cut-off times differ, and statuses arrive in five different formats. Appfront builds shipping software that selects the carrier for each consignment itself, based on rules you understand, produces the label and accompanying documents, and brings all events together in a status model your organisation can explain.
What makes multicarrier shipping different
With a single carrier, shipping is a simple task: pick the order, attach the label, done. The software only needs to do one thing, and nearly any package can handle that. Once you have several carriers working side by side, the nature of the problem changes, because a decision enters the picture. That decision is made per shipment: the contents, weight, dimensions, destination, the promise made to the customer and the time of day together determine which carrier and which service are suitable. Two orders from the same customer on the same day can therefore belong with different carriers.
Are you in the right place? This page is about routing itself, and about running several carriers side by side in one process. If your main concern is checking afterwards that the carrier's invoice is correct, including weight corrections and surcharges, then parcel audit software is what you need. If you want an integration with a shipping platform, a MyParcel integration is the quicker route. This page is about the question that comes before that: which carrier gets this shipment, and why.
The second difference lies in aftercare. Each carrier supplies its own events, with its own codes, its own timestamps and its own interpretation of what delivered means. If you pass those codes straight through to customer service, the webshop and the accounts department, you build the differences between carriers into your entire organisation. A dedicated model on top is therefore not a luxury but the foundation everything else rests on.
Shipping with multiple carriers is rarely a choice made out of ambition. It usually starts with a constraint: a carrier that will not accept parcels above a certain size, a country where your usual partner is expensive or slow, a business customer who prescribes a particular carrier, or a peak period in which one partner's collection capacity runs out. From that point on, there are two or three portals open side by side and the logic moves into people's heads. You notice it in the symptoms: a spreadsheet showing who ships what and where, a packing station where the experienced member of staff is quicker than the newcomer because they know the rules, and a customer service desk with three tabs open. These symptoms are not carelessness, but the consequence of logic that has never been written down anywhere.
The choice is made per shipment
Not per customer and not per webshop. Two orders from the same customer can belong with different carriers.
Each carrier has its own language
Different fields, different product names, different status codes. Without a dedicated model, you inherit those differences throughout your entire process.
The exceptions take the most time
Shipments that simply arrive demand no attention. The work lies in the shipments that get stuck.
Carrier selection per shipment, based on rules you understand yourself
A set of rules sounds simple until you write it down. In practice the choice consists of two steps that you need to keep separate: first exclude what cannot work, then rank what can. That separation prevents the most common mistake, which is a preference list in which a hard constraint has been included as a preference. Exclusion concerns the limits of the product: the country or postcode lies outside the delivery area, the weight or longest side falls outside the size limits, the girth is too large, the contents require handling that this carrier does not offer, or the registration time falls after today's cut-off. What remains after that step is the set of valid options, and only there does the weighing begin.
Ranking involves more than the freight price. The promise to the customer often comes first: if a delivery date or time window was selected at checkout, anything that won't meet that day falls away. Next come the negotiated price agreements, and the comparison has to be fair. Carriers don't all calculate weight the same way. Alongside the actual weight there is the volumetric weight, where length, width and height are converted using a carrier-specific divisor, and the higher of the two becomes the basis for pricing. Two carriers with similar rate cards can therefore come out very differently for the same box full of air. If your software only uses the actual weight, the choice looks right and then turns out differently on the invoice.
Other factors also come into play that have nothing to do with the individual shipment. Anyone who has split their volume across carriers will usually have agreed on volumes, and those volumes are a condition of the choice. A system that optimises each shipment in isolation may discover at the end of the period that a carrier's agreed quantity hasn't been reached. A counter per carrier and per period is therefore needed, one that feeds into the ranking. The same applies to daily capacity: if a carrier has a maximum per collection run, or its roll containers are full, the remaining shipments need to go elsewhere, without anyone having to adjust rules by hand.
A question that is often overlooked: at what point is the choice made? At order intake you know the destination and the promise, but not the actual weight or which box it will fit into. At packing you know those things, but by then the customer has already been informed. Most shippers therefore need two moments. A provisional choice at the order determines what you tell the customer and what you charge. A definitive choice at the point of label creation uses the actual box and actual weight. If the second differs from the first, that difference should be visible, because it is precisely the gap between what you expected and what the carrier will ultimately invoice.
Finally, the outcome must be explainable. Each shipment should record which options were available, which were eliminated and why, and which rule selected the winner. That may seem a small detail, until the first time someone on the warehouse floor says the system is behaving strangely. Without a record, that conversation cannot be settled, and the rule set is loosened out of caution until it no longer means anything. With a record, you can reconstruct a decision, even much later, and see which rule decides most often in practice. That last point is surprisingly often a rule that nobody consciously chose any more.
When the cheapest choice turns out to be the most expensive
The temptation with carrier comparison is to sort on freight price alone. That works well for shipments that arrive without trouble. However, the total cost of a shipment also includes what happens when things go wrong: a failed first delivery attempt, a customer who calls, a parcel sent to a pickup point where the recipient never collects it, a shipment returned to sender. These costs partly fall on the carrier and partly on you, in customer contact and in reshipping. They differ by carrier, by destination and by type of address, and it is precisely those differences that you don't see in a comparison that stops at the freight price.
You can incorporate this without getting lost in models. For each carrier and each zone, track how often the first delivery attempt succeeds, how often a shipment ends up at a pickup point, and how often a return follows. Those figures come from your own status model, so you already have them as soon as that model is in place. Translate them into a surcharge on the freight price within the ranking, and the choice will shift in exactly the places where that pays off. If you ship to both business and consumer recipients, you will likely find that the same carrier is strong in one segment and weak in another.
If shipments leave the Union or enter under a special regime, there is a licensing side to consider. See software for customs procedures and registration.
What multicarrier shipping software needs to do
These parts are connected. A selection rule without a traceable outcome leads to arguments, a label without address checking leads to failed deliveries, and a status model without the raw messages behind it leaves you stuck the moment a carrier changes its codes.
What is not included matters just as much. This is not a planning system for your own transport, nor a freight module for pallets with a haulier. If you drive yourself, or your volume moves on consignment notes rather than parcel labels, you need different tools, with routes and loading capacity at the core: see custom transport software development.
A rule set with traceable outcomes
Conditions you manage yourself, with the reason each carrier was chosen recorded against every shipment.
Labels in your printer's format
Thermal or document, in the correct size, with a queue that handles reprinting and cancellation.
Customs data per line
Commodity code, country of origin, value and weight per item line, plus the delivery terms of the shipment.
Your own status model with the raw source
Events from all carriers mapped onto your own steps, with the unprocessed message stored alongside the mapping.
Returns as their own shipment
A return gets its own number, its own carrier and its own status, linked to the order and to receipt at the warehouse.
One integration layer per carrier
Each carrier sits behind its own translation layer with its own tests, so a change at one provider does not affect the rest.
Labels and documents that are right first time
The label is where all preparation comes together, and where mistakes are most expensive. A shipment that leaves with a wrong address or the wrong product comes back as customer contact, a second dispatch and a correction on the invoice. Most of those errors can be spotted in advance. An address check that validates postcode, house number and addition against a reference source catches the typos and the missing additions that would otherwise surface with the driver. For destinations outside the Netherlands, a check on the address structure is also needed, as not every country follows the same pattern of street, number and postcode.
Then comes the printing itself, which is less trivial than it seems. Carriers supply labels as a document or in printer language. A thermal printer needs the latter, at that device's resolution, and a label that looks fine on an office printer can come out of the roll unreadable on the warehouse floor. At a packing station the queue should run per workstation, with reprinting possible without registering a new shipment, because every new registration creates a new consignment number. Unused numbers must be cancelled within the carrier's window, or they will turn up later in invoicing.
The label holds more than the address. The carrier reads its own barcode carrying the consignment number, and there is also data that drives its sorting, such as a routing or depot code generated by its system, which you cannot devise yourself. That is why you have labels produced by the carrier rather than rebuilding them, even though the layout may look simple. What you add is your own reference: an order number or a link to the pick list that your staff can scan, so that a box can be traced within your own process without first opening the carrier's portal.
What matters most is holding on to what has been registered. The moment the carrier issues a tracking number, the shipment exists in the outside world. From that point on, your system should know which number belongs to which order, which box and which contents, even if the parcel is repacked afterwards. Splitting is a topic in its own right: multiple boxes under one order, each with its own number, and a status view that only counts as complete once the last piece has arrived.
Closing the day is part of the handover. Carriers need to know which shipments are in the collection run, and that list is more than a formality. Shipments missing from it may be treated as unknown at the sorting centre, and shipments that are on it but don't leave stay open. An end-of-day close per carrier, with a list you can look back at, stops the argument from being settled on gut feeling the next morning. If you ship from several sites or under several brands, that close should run per site and per contract, because carriers tie their collection run to a specific address and a specific customer number.
Shipments crossing borders
As soon as a shipment leaves or enters the European Union, the work shifts to the data. For customs, the focus is not the box but the contents, line by line: a description that an outsider can understand, the commodity code, the country of origin, the quantity, the weight and the value. The consignment also needs the delivery terms, meaning whether the recipient or you pays the import duties, and the registration number under which your business is known to customs. The carrier usually files the declaration, but it does so with your data, and an incomplete line only becomes their problem once the parcel is held up.
That means this data needs to be right much earlier in your chain than at packing. A commodity code belongs to the article, not the shipment, so it belongs in article management, with a check that blocks new articles without a code from international sale. For the shipment itself, carriers need the data electronically in advance, in the format their customs process requires, and a missing field leads to a rejection rather than a warning. Store the prepared documents with the shipment, so that a customer or inspector can later receive a copy without a new label being created.
- Address checked before the label is made
- Label in the format the printer actually understands
- Tracking number recorded at the moment of registration
- Cancelling within the carrier's window
- Commodity code and origin per article line
- Documents retrievable again without a new label
Test your idea first: a working prototype in 1 day
With OneDayBuild, we turn your idea into something tangible in one day for €1,150, so you can see whether further development is worth the investment. Decide to go ahead with the full build? Then we credit the full cost.
Explore OneDayBuild →Track and trace across five carriers, a status model
Ask any shipper where their parcels are and the answer is usually that it has to be looked up per carrier. That is precisely the problem. As long as statuses stay in each carrier's language, there is no overview, customer service cannot work from a worklist, and nobody can say how many shipments are stuck right now. The solution is not a prettier display but a model of your own: a limited, fixed set of steps that describes what happens to a shipment, onto which each carrier's codes are mapped. Registered, received, in transit, out for delivery, delivered, ready at a service point, failed attempt, refused, returned, lost: most organisations need no more than that.
That image comes with three commitments you cannot easily add later. First, alongside the mapped step, keep the raw carrier message too, with its own code and its own wording. If a carrier changes a code, or your mapping turns out to be wrong, you can remap without losing history. Second, record two timestamps: the moment the carrier says the event happened, and the moment you received the message. These can diverge, sometimes considerably, and only with both can you separate sequence from delay. Third, give every event a key that lets you recognise duplicate messages.
Messages arrive out of order and from several directions. One carrier pushes events to an address on your side, another expects you to poll for them, and a third does both with different content. A message may arrive twice, or in the wrong order, such as a delivery arriving before the sorting-centre scan. Your model must not be thrown by this: the shipment's status follows from the event with the latest carrier timestamp, not from the last message that came in. And delivered is not a terminal state, since a refusal or a return can still follow.
The final step is that someone acts on it. A status model that only fills a timeline per shipment is a reference work. It becomes a tool once you set thresholds on it: shipments without a pickup beyond that carrier's window, shipments that have been out for delivery too long, parcels at a service point whose holding period is running out, returns that were registered but never arrived. Each of those groups is a work list with an owner, and the size of those lists is at the same time your quality measure. If you don't build them, customer service does the same work reactively, call by call, without seeing that fifty other shipments have the same problem.
What you get from this is more than a tidy overview. Once every carrier speaks the same steps, you can compare: which carrier holds back which share of shipments, where the first scan takes longest, which destinations generate the most second attempts. The same steps feed the page your customer sees, and that only works if the wording is yours and doesn't come from five different sources. For what that side looks like, read building a track and trace system.
Failures, exceptions and the day a carrier changes
A shipment that arrives needs no attention. The work lies in the rest, and that rest is larger than most businesses assume. Failures often begin with silence: a label has been made, but no first scan follows, because the box was behind a roll container or didn't go out on the collection run. Without detection for absence, you only notice when the customer calls. The rule itself is simple: if a shipment has no pickup after that carrier's expected window, it belongs on a work list, with the reason attached.
Then comes the set of familiar exceptions: incorrect address, recipient not at home, parcel damaged, shipment held at customs, parcel not collected from the service point, and the case nobody wants, lost. Each of these has its own follow-up step, and that step is more than a phone call. An incorrect address means passing on a correction, which with one carrier goes through a portal and with another through a message in the integration. Damage and loss mean a claim, with a deadline that differs per carrier and with evidence you only have if you kept it with the shipment.
For business shipments, proof of delivery matters. If you sell on terms where receipt can be disputed, you want to be able to show the signature: the name, the time and, where the carrier records it, the signature or photo of the handover. Carriers only let you retrieve these for a limited period, after which they are gone. Fetch them as soon as a parcel is delivered and store them with the shipment, and a dispute about a non-received delivery becomes a matter of looking something up rather than a hunt across two portals.
Returns belong in this list because they have the same exceptions in practice, just in reverse. A return is its own shipment, with its own number, its own carrier and its own status, not a flag on the original order. Only then can you address the cases that really matter: a return that was registered but never arrives, a customer who ships with their own label, a parcel that comes back without a registration, or a refusal that the carrier sends back as a return. You can read more about how to set up that process in returns management software.
And then something changes on the carrier's side. That happens regularly, in three forms. A technical change: a new version of the integration, a field that becomes mandatory, authentication that works differently. A commercial change: new price lists, different zones, different surcharges, a fuel surcharge that moves each period. And a product change: a service that is discontinued, a new delivery option, different maximum dimensions. All three affect your software, but only the first produces an error message. The other two let your system carry on working with outdated assumptions, and that is the most dangerous of the three.
There is a way to build for this. Each carrier sits behind its own translation layer that converts your shipment model into its format and maps its responses back to your model, so the rest of the system never needs to know any carrier from the inside. Each layer comes with tests that run against that carrier's test environment, so an announced version change surfaces before its effective date passes. Pricing agreements, zones, surcharges and maximum dimensions are stored as data in the system, with an effective date, rather than hidden in the code. A new price list is then an import with a date, not a code change that has to go through acceptance.
Adding a carrier is more than filling in a key, though. There's a contract with a customer number per site or per brand, a test environment where you register shipments, and with most partners approval of your labels before you can go live: they check that the barcode is readable and that the layout doesn't interfere with their sorting. On top of that, each carrier sets its own requirements for the data, for example a telephone number or email address for the recipient as soon as you work with delivery notifications. Factor that in for the first carrier you add. The second and third go faster, but not because their integration is any simpler.
That raises the honest question: should you build this yourself? For many shippers, no. There are mature multi-carrier platforms that offer dozens of carriers out of the box, maintain the integrations and come with a rules screen, and Dutch providers are well represented among them. If your choice fits that screen and your volume goes through common products, you buy it and your effort shifts from building to configuring. Custom development pays off when the choice depends on data that only lives in your own processes, when a shipment only takes its final shape while it's being packed, or when you need to split orders across carriers according to rules the platform doesn't know. Often the middle route is the answer: a platform for the integrations, your own logic on top. You can read how we weigh that trade-off in automating logistics processes.
If you specifically need the carrier integration and label generation, have a look at carrier integration and shipping label software.
- A platform if your rules fit its rule screen
- Platform if you mainly need integrations, not logic
- Custom development for routing rules drawn from your own processes
- Custom development if the shipment only takes shape at packing
- Middle route: a platform for the integrations, your own choice logic on top
Frequently asked questions about multi-carrier shipping software
An integration sends your shipments to one partner and uses that partner's choice logic. Multi-carrier shipping software makes the choice itself: the system determines per shipment which carrier and which product fit, keeps track of what has been registered and which events followed, and keeps working when a carrier is added or drops out. If you're looking for that one integration, a MyParcel integration is the shorter route. If you work with several contracts side by side, the choice logic itself is the subject.
Based on rules you define yourself, applied in a fixed order. First it rules out what cannot work: a destination outside the carrier's coverage, weight or dimensions outside the limits of the product, a shipment requiring age verification or containing dangerous goods, or a registration after that day's cut-off time. What remains is ranked by the promise to the customer, the freight cost according to your own rate agreements, and the capacity still available within a volume agreement. The outcome should be traceable per shipment, with the rule that made the choice.
By defining your own status model and mapping each carrier's codes onto it, rather than showing every carrier's codes side by side. That model describes what happens to the shipment: registered, collected, in transit, out for delivery, delivered, ready at a pickup point, failed attempt, refused, returned, lost. Alongside that, you store each event unprocessed, with the carrier's timestamp and the time you received it, so you can revise a mapping later without losing the source.
That is not an incident but recurring maintenance, and the system should be built with that in mind. Each carrier has its own layer that translates your shipment model into that party's format, so a change at one carrier does not affect the rest. Each layer comes with tests that run against the carrier's test environment, so an announced version change surfaces before the effective date passes. Rate agreements, zones and surcharges are held as data in the system, with an effective date, rather than buried in the code.
That is a different subject. This page is about the choice beforehand and the execution: which carrier, which label, which documents, which status. Setting the carrier's invoice against the shipments you actually registered, with weight corrections and surcharges included, is work done afterwards, with its own data model and its own dispute process. For that, parcel audit software is the right starting point. The two do connect, however, because the expected costs from the routing logic form the benchmark for that check.
Often yes, and for many shippers that is the more sensible route. There are mature multi-carrier platforms that offer dozens of carriers out of the box and maintain the integrations themselves. If your choice logic fits their rules screen and your volume goes through common products, you buy that. Custom development becomes worthwhile when the choice depends on data that only lives in your own processes, when a shipment only takes its final shape during order picking, or when you need to split shipments across carriers according to rules the platform doesn't know.
Related services
Parcel audit software
Does the carrier's invoice match the shipments you actually registered? Weight corrections, surcharges and labels that were never sent you check afterwards, with your own dispute process. That is the subject of building parcel audit software.
MyParcel integration
If you work with a shipping platform and mainly need that one integration, with labels and statuses flowing back into your own system, then building a MyParcel integration is a shorter route than a custom choice layer.
Track and trace for customers
You also want to show the statuses you bring together to the recipient, in your own words and with your own messages instead of ten different carrier pages. That calls for a custom status page and custom notifications: building a track and trace system.
Returns management and warehousing
Returns that go beyond a label, covering inspection, restocking and refunds, are handled by building custom returns management software. If the bottleneck lies within the warehouse itself, at receiving, locations and order picking, then a custom WMS is the place to start.
Your shipping process across carriers
Tell us which carriers you work with, which selection rules currently live in someone's head or in a spreadsheet, and what happens today when a shipment is never scanned after registration. Those three answers usually show whether a platform, custom development or a combination fits best, and which part you should tackle first.