Thomas Richter
Picture this. It is 10:47 on a Tuesday morning. Your warehouse team is processing the morning batch - 340 shipments, a mix of DHL and InPost. Labels are printing. Everything is flowing. Then DHL's API starts returning errors. Not every request, just most of them. Some time out after 30 seconds. Others come back with cryptic messages that are not in any documentation you can find.
Your warehouse stops. Half the batch is stuck. The team switches to manually creating labels through DHL's web portal, one by one. By the time the API recovers 90 minutes later, you have lost half a day of throughput and your ops manager is questioning every life decision that led to this moment.
I have seen this happen more times than I can count. And it is entirely preventable.
Carrier APIs are not as reliable as you think
Here is something carrier sales reps will never tell you. Most carrier APIs do not have the uptime guarantees you would expect from critical infrastructure. We monitor carrier API availability across our network, and the reality is sobering.
Most major European carriers experience two to five significant API incidents per month. Average incident duration is 45 to 120 minutes. Partial degradation - slow responses and intermittent errors - is three times more common than full outages. And peak season in November and December sees roughly double the incident rate.
If you ship with a single carrier, the maths is simple. Three incidents per month at 90 minutes each means 4.5 hours of lost fulfillment time every month. During peak season you are looking at nine hours or more. That is orders not shipping, SLAs being missed, and customers getting their packages a day late.
Retries are not a strategy
The first thing most engineering teams implement is retry logic. Request failed? Wait two seconds, try again. Still failing? Wait four seconds. Then eight. Exponential backoff.
This is fine for transient blips - a single server error, a momentary network hiccup. It does absolutely nothing for sustained outages. Your system just sits there, patiently retrying every few seconds for 90 minutes, while parcels pile up on the packing bench.
Retries are table stakes. They are not resilience.
Real fallback means automatic carrier switching
A proper fallback strategy means that when Carrier A is unavailable, shipments automatically route to Carrier B without human intervention. The warehouse does not stop. Labels keep printing. The only difference is the logo on the label.
With the Uniship Shipment API, you define a carrier preference list for each shipment. Think of it as a fallback chain. The system tries your first choice. If that carrier's API is degraded or returning errors, it automatically falls to your second choice. If that one is also having issues - rare, but it happens - it moves to the third.
Your system gets back a successful shipment response either way. No retry loops. No warehouse downtime. No frantic messages in Slack.
I remember a particularly bad afternoon last December when two major carriers had overlapping outages during peak season. Merchants using single-carrier integrations were completely stuck. Those with fallback chains configured barely noticed. Their labels kept printing, just with a different carrier name on them.
Knowing before your shipments fail
Reactive fallback is good. Proactive detection is better. You do not want to discover a carrier is down because your first 20 shipment requests fail. You want to know before you even try.
Two approaches work well together here. The first is synthetic health checks - making a lightweight validation request to each carrier every 60 seconds. If it fails three consecutive times, that carrier gets marked as degraded. When a real shipment request comes in, the system already knows to skip the unhealthy carrier.
The second is real-time success rate monitoring. You track the success and failure ratio of actual shipment creation requests over a rolling five-minute window. If the success rate for a carrier drops below 90 percent, fallback triggers automatically. This catches partial degradation that synthetic checks might miss - like an API that responds to health checks but fails on actual label generation.
Uniship runs both of these internally across all integrated carriers. When we detect degradation, the routing engine adjusts before your shipment requests are affected. You can also subscribe to carrier health events via webhooks if you want visibility into what is happening behind the scenes.
Designing sensible fallback chains
Not every carrier is interchangeable. You need to think about fallback chains carefully.
For domestic standard parcels, this is the easiest case. Most carriers offer comparable service. DHL to DPD to GLS to UPS works well for Germany. For Poland, InPost locker orders are trickier - your fallback might be InPost courier to DPD pickup point, since no other carrier matches InPost's locker network.
Express and time-definite shipments have fewer options. If DHL Express goes down, your fallback might be UPS Express or FedEx. Make sure your fallback carrier has a genuine express service to the destination, not just priority branding on a three-day service.
International shipments require extra thought. Cross-border parcels often have customs requirements that not all carriers handle equally. Your fallback chain should only include carriers that support the destination country and the customs flow you need.
And oversized or heavy parcels deserve their own fallback logic. Some carriers have stricter weight and dimension limits. If your primary carrier for heavy freight goes down, make sure the fallback actually accepts 31 kilogram parcels and will not reject them at label creation.
The cost objection
This is the question everyone asks. If DHL is my cheapest option and I fall back to DPD, I am paying more per shipment.
Yes. You might be. Maybe 30 to 80 cents more. But let me compare that to the alternative. A 90-minute warehouse outage delays 60 to 70 shipments for a merchant doing 500 parcels a day. The customer satisfaction cost alone - delayed deliveries, support tickets, potential marketplace penalties - dwarfs the carrier price difference.
And honestly, for most domestic standard shipments within Europe, the price gap between major carriers is smaller than people assume. Usually under 10 percent.
Label consistency matters
One practical concern with automatic carrier switching - your warehouse team might be set up for a specific label format. DHL labels look different from DPD labels. Barcode positions vary.
This is where the Printing API comes in. It normalizes label output across carriers into consistent formats. Same PDF dimensions. Same barcode placement zone. Same orientation. Your thermal printer does not care which carrier generated the label. It just prints.
Start simple then automate
If you are not doing any fallback today, start with the basics. Define a primary and secondary carrier for each shipping lane. Add proper timeout handling to your carrier integration - 10 seconds, not 60. Monitor carrier success rates, even if it is just a simple dashboard. When you detect failures, have a documented manual process for switching carriers.
Then automate it. The goal is that your warehouse team never has to think about carrier API availability. Shipments go out. Labels print. Customers get their packages. What is happening at the carrier API level is someone else's problem.
Preferably ours.