Shipping Internals is a publication about the software underneath shipping and logistics. Carrier APIs, canonical data models, rating and label pipelines, tracking normalization, and the parts of the system that only become visible when they break.
Written by Daniel Kobina. Published by Eben Labs.
Why it exists
There are hundreds of carriers, and they agree on almost nothing. Each has its own idea of what a shipment is, what a rate request needs, what a tracking event means, and what counts as an error. Teams integrating them find this out one carrier at a time, usually in production, usually after the abstraction they started with has stopped holding.
The view from the other side is no better. If you are the carrier, you are publishing an interface that every integrator will hold you to, with no standard to conform to and little visibility into what the result looks like from where they sit.
I have worked both sides of that interface. I built Karrio (the first universal open-source multi-carrier shipping API) to make carriers that disagree answer to one model. At Teleship I built the carrier-side API for a cross-border logistics operation, where the job was to be the interface rather than to consume one. From either direction the problem was never a shortage of engineering. It was that nobody agrees on the interfaces.
This publication is the working notes from that argument.
What gets published
Field notes, mostly. Specific problems with specific shapes. How to model a shipment so the next carrier does not break it. What idempotency actually costs once rating is in the hot path. The failure modes of credential architecture that only appear at the second carrier. Why tracking normalization is harder than the docs make it look.
Alongside the notes, a standardized shipping API specification. That work is Forthcoming. I would rather describe it once there is something to read than put a date on it now. It will live at shippinginternals.dev.
There is no fixed schedule, and no promise of one.
Who it is for
Engineers integrating carriers, whether that is the whole product or one unfortunate corner of it. Platform engineers at ecommerce and marketplace companies who inherited shipping and now own it. And the engineers at carriers and logistics providers building the API on the other side of that relationship, who have the same modelling problem pointed the other way.
If you are somewhere between three and twelve months into building this and it has started to hurt more than it did at the start, you are the reader I have in mind.
Who writes it
Daniel Kobina. I founded Karrio in 2020 and ran it until the acquisition by JTL-Software in 2026. It reached 30+ carriers integrated, 20K+ OSS downloads and 1M+ live transactions through the framework, built by a small team, open source from the start.
I was also a founding engineer at Teleship, building the carrier-side API for a cross-border logistics company. That is where I stopped reading a difficult carrier API as bad engineering. Most of what looks arbitrary from the outside is load-bearing on the inside, holding up a tariff rule, a customs requirement or a sortation constraint that the integrator never sees. Telling those apart from the genuine mistakes is a large part of integrating well, and it is most of what I have to say that an integrator alone could not.
I run Eben Labs, a small lab working on sovereign tech through open infrastructure and standards. Part of that is a logistics technology advisory practice, a few engagements a year spent inside other teams’ carrier integration layers. Those engagements are where most of what gets published here comes from. That is the observatory.
