Why We Built UniShip - And Why Europe Needed It

I need to tell you about the moment this whole thing clicked for me. It was late 2022, and I was sitting in a meeting room in Madrid with a mid-size fashion retailer that sold across six European countries. Their logistics manager had a spreadsheet open - fourteen columns, one for each carrier they used. He was explaining how every single carrier had its own portal, its own login, its own label format, and its own way of reporting tracking updates.

He looked exhausted.

That meeting stuck with me. Not because the problem was new - I had been working in logistics for years and knew this pain firsthand - but because nobody seemed to be fixing it properly.

The fragmentation problem

Here is something most people outside European e-commerce do not realize. In the United States, you have maybe four or five carriers that cover nearly everything. USPS, UPS, FedEx, DHL. Done. But a Polish retailer selling across the EU might need InPost for domestic locker deliveries because Polish shoppers overwhelmingly prefer lockers. They need DPD for door-to-door within Poland. DHL Express for shipments to Germany. GLS for the Benelux region. Correos for Spain. Colissimo for France. And that is just the starting list.

Seven carriers minimum. Each with its own authentication system, its own data format, its own error codes, and its own quirks that you only discover after something goes wrong in production.

Some of these APIs use modern REST conventions. Some still rely on SOAP. I have personally encountered a carrier that wanted CSV files uploaded via SFTP. In 2024. That is not a joke.

What we tried before building UniShip

Before we committed to building this, I spent months evaluating what already existed. The options boiled down to three paths, and none of them worked.

The first option was to build custom integrations for every carrier. A team I worked with tried this. It took three months just to get four carriers working reliably. And then the maintenance started eating twenty or more hours every single week, because carrier APIs change more often than you would expect.

The second option was to use a shipping platform with a visual dashboard. Tools like Sendcloud or ShipStation are genuinely great if you want to point and click your way through shipments. But the businesses I was working with needed programmatic control. They needed to select carriers dynamically based on package dimensions, destination, cost, and delivery speed. They needed an API, not a user interface.

The third option was a US-focused aggregator. EasyPost and Shippo are solid products. I respect what they have built. But their European carrier coverage has real gaps. Try getting InPost Paczkomaty or Poczta Polska through them. You simply cannot.

None of these paths led to what we actually needed - a single, clean API that treated European carriers as first-class citizens.

So we built it ourselves

The core idea behind UniShip is almost embarrassingly simple. One API call to create a shipment, regardless of which carrier handles the delivery. One webhook format for tracking updates via our Tracking API. One label endpoint that always returns a PDF - whether the underlying carrier gives you ZPL, EPL, or a base64-encoded PNG. Yes, that last one is real. I wish I were making it up.

You send us the origin, the destination, the parcel details, and the carrier you want. We handle the translation. The response comes back in the same structure whether you are shipping via InPost, DHL, DPD, or any of the forty-plus carriers we support. Same fields. Same tracking vocabulary. Same label format.

That consistency is the product.

What makes this genuinely hard

Building an aggregation layer sounds straightforward until you are actually doing it. A few of the things that kept our engineering team up at night deserve mention.

Carrier APIs go down. Not occasionally - regularly. We have seen major carriers have multi-hour outages on Black Friday. UniShip handles failover and queuing so your checkout flow keeps working even when a carrier decides to take a nap.

Label formats are chaos. One carrier returns a 4x6 inch label. Another returns A4 with the label tucked into the top-left corner. Another gives you a 10x15 centimeter thermal label. Our Printing API normalizes everything so warehouse teams can run a print queue without losing their minds.

Tracking events mean different things depending on who you ask. "In transit" from DHL means the package is on a truck. "In transit" from another carrier might mean it just left the sorting facility. We mapped every carrier's event taxonomy to a unified set of statuses. That work alone took months.

And then there are addresses. German addresses need the house number in a different field than Polish ones. French addresses have specific formatting rules. Dutch postcodes require a space in the middle. Our Address API handles validation and normalization across more than thirty European countries so these differences never become your problem.

Where we are now

We launched the beta in late 2023 and went live in early 2024. Our Shipment API and Tracking API are in production handling thousands of shipments daily. The Printing API and PUDO Map are in beta and growing fast.

We are not trying to replace your warehouse management system or your 3PL. We are the translation layer between your software and the carriers. Integrate once, ship everywhere in Europe.

I think back to that logistics manager in Madrid with his fourteen-column spreadsheet. He was one of the early testers. Last month he told me his team spends about ten minutes a day on carrier management now instead of two hours.