What is a shipping API? How it works and what it does
A shipping API is a set of web endpoints that lets your application talk to carriers and shipping software programmatically, so you can fetch live rates, buy and print labels, validate addresses, and track packages without a human logging into a carrier website. Instead of copying tracking numbers by hand or manually comparing carrier prices, your code sends a structured request and gets back a structured response in seconds. For an ecommerce seller or a consolidator moving hundreds or thousands of parcels, that is the difference between a checkout that quotes real shipping cost and a warehouse that ships on autopilot.
This guide explains what a shipping API does, how the request and response flow works, and how the common operations (rates, labels, tracking, address validation) fit together. It is written for developers who are wiring shipping into a store or platform for the first time.
What a shipping API actually does
At its core, a shipping API is an HTTP interface in front of one or more carriers. You send JSON, you get JSON back. The value is that a single, consistent interface hides the differences between carriers, each of which has its own systems, data formats, and quirks. A multi-carrier shipping API takes that further: one integration reaches many carriers at once, so you are not building and maintaining a separate connection for each one.
The everyday jobs a shipping API handles break down into four operations:
- Rating - given an origin, a destination, and package details, return the available services and their prices. This powers checkout quotes and rate shopping across carriers.
- Label creation - buy a shipment and return a printable label (usually a PDF or a ZPL string for thermal printers) plus a tracking number.
- Tracking - report where a package is, either by polling a status endpoint or by receiving webhook events as the status changes.
- Address validation - check that a destination address is real and deliverable before you spend money printing a label for it.
Some APIs add pickups, manifests, customs documents for international shipments, and returns. But the four above are the backbone of nearly every integration.
How a shipping API request works
Every shipping API call follows the same shape as any modern REST API. You authenticate, you POST a JSON body describing what you want, and you read a JSON response. Here is an illustrative rate request. This is generic pseudo-REST to show the pattern, not the exact Expership contract; the real field names and endpoints are in the Expership API reference at /developers.
POST /rates
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json
{
"from": { "postal_code": "10001", "country": "US" },
"to": { "postal_code": "94105", "country": "US" },
"parcel": {
"weight_oz": 32,
"length_in": 12,
"width_in": 9,
"height_in": 4
}
}A response returns a list of quoted services you can present to a buyer or pick from automatically:
{
"rates": [
{ "carrier": "CarrierA", "service": "Ground", "amount": 8.42, "currency": "USD", "est_days": 4 },
{ "carrier": "CarrierB", "service": "Express", "amount": 21.10, "currency": "USD", "est_days": 1 }
]
}The exact fields differ by provider, so always check the reference for the shape you will actually receive. But the mental model is stable: describe the shipment, get back priced options.
Authentication
Most shipping APIs authenticate with an API key or token that you send in a header on every request. Treat that key like a password. Keep it server-side, never ship it in front-end code or a mobile app, and rotate it if it leaks. Anyone with your key can spend money buying labels on your account.
Sandbox versus production
Good providers give you a test or sandbox environment that returns realistic responses without charging you or generating real labels. Build and test against the sandbox first, then switch to production credentials once your flow is solid. Always verify exact sandbox behavior in the provider's docs at /developers.
The four core operations in practice
Rating and rate shopping
Rating is usually where teams start because it drives checkout. You send package dimensions and weight along with the origin and destination, and the API returns every eligible service with a price. From there you can show the buyer a menu, or run rate shopping to automatically pick the cheapest service that meets your delivery promise. Because carriers often bill on dimensional weight rather than actual weight, sending accurate dimensions matters. Send the wrong box size and your quoted rate will not match the invoice.
Label creation
Once a service is chosen, you buy the shipment and the API returns a label file plus a tracking number. See how to create a shipping label with an API for the full flow, including printing formats and handling voids.
Tracking
After a label is printed, the tracking number becomes the thread you follow. You can poll a tracking endpoint on a schedule, but the modern approach is webhooks: the carrier or platform POSTs an event to your server whenever the status changes. Our guide on the shipping tracking API and webhooks covers both patterns.
Address validation
Bad addresses cause failed deliveries, surcharges, and returns. An address validation API checks and standardizes an address before you commit money to a label, which is one of the cheapest error-prevention steps you can add.
Why use a shipping API instead of direct carrier integrations
You can integrate each carrier directly, but you then own every carrier's authentication, data format, edge cases, and outages. A multi-carrier shipping API consolidates that into one integration and one data model. The tradeoffs:
| Approach | Pros | Cons |
|---|---|---|
| Direct carrier integrations | Full control, no middle layer | Build and maintain each connection separately; every carrier is a different codebase |
| Multi-carrier shipping API | One integration, consistent data model, easy to add carriers and rate shop | Depend on the provider's coverage and uptime |
For most small and growing sellers, the multi-carrier route wins on speed and maintenance cost. If you want the bigger picture of where an API fits alongside the rest of the stack, read what is shipping software. This article is part of our hub on shipping APIs for developers.
Getting started with the Expership shipping API
Expership offers a multi-carrier shipping API aimed at ecommerce sellers and consolidators, including many overseas businesses shipping into the U.S. You can explore the endpoints and reference docs at /developers, see the wider software at /platform, or create an account to get keys and start testing in a sandbox.
Frequently asked questions
What is a shipping API in simple terms?
It is a web service your code calls to do shipping tasks automatically: get rates, buy and print labels, validate addresses, and track packages. Instead of using a carrier's website by hand, your application sends a request and gets a structured response back.
What is the difference between a shipping API and a carrier API?
A carrier API connects you to one carrier. A multi-carrier shipping API sits in front of many carriers and gives you one consistent interface, so a single integration can rate, label, and track across all of them and let you rate shop between them.
Do I need a shipping API for a small store?
If you ship more than a handful of orders a week, yes. Even at low volume, automated rate quotes at checkout and one-click label printing save time and reduce errors. The value grows quickly as order volume rises.
Is a shipping API hard to integrate?
If you have built against any REST API, the pattern is familiar: authenticate with a key, POST JSON, read JSON. Start in the sandbox, wire up rating first, then labels and tracking. Most teams have a working prototype in a day or two.
How much does a shipping API cost?
Pricing varies by provider and usually depends on volume and which features you use. Check the pricing and plan details for the specific provider. For Expership, see /platform and /developers.