Batch Shipment Limits Across 9 Carrier APIs

Batch Shipment Limits Across 9 Carrier APIs

Every carrier API has a hard ceiling on how many shipments, packages, or customs line items you can push through in a single call. These batch shipment API limits are rarely the headline feature in vendor marketing, but they decide how your adapters chunk traffic the moment a sales peak sends 50,000 orders into your queue at once. This post lists the figures as published, with sources, as of early October 2026.

Method: what's in scope and what isn't

The figures below come from the public developer documentation of each platform, pulled between late September and early October 2026. No load testing was performed here, so these are documented ceilings, not measured throughput under failure conditions. Freight/LTL batch limits, carrier-side request throttling, and privately negotiated enterprise overrides are out of scope. Where a vendor has not published a hard number, the table says "Not published", not an estimate.

Table 1: shipment and label batch limits

The gap between carrier-native limits and what multi-carrier aggregators expose is the first thing that stands out. A single FedEx account might cap you at 40 synchronous packages, while a Shippo batch call accepts thousands.

Some detail behind the numbers matters more than the numbers themselves. Open shipping is limited to 40 packages per shipment for synchronous mode, 300 packages per shipment for asynchronous mode and 999 packages per shipment for international commodities, which tells you FedEx itself treats 40 as the break point between "instant" and "poll for a job ID" behaviour. On the multi-piece shipping workflow that uses a master tracking number, the maximum packages allowed in this processing option are 200. Its batch tracking service is far tighter: the maximum number of packages within a single-track transaction is limited to 30.

On the aggregator side, ShipStation's own help documentation lays out carrier-specific ceilings cleanly. UPS supports up to 20 packages per shipment, FedEx supports up to 100 packages per shipment, and DHL Express supports up to 999 packages per shipment, while USPS does not support multi-package labels at all, forcing a split-order workflow instead. That's a wider spread across four carriers, behind a single aggregator UI, than you'd expect.

Shippo's multi-carrier batch endpoint is the largest hard ceiling in this list: the Batch endpoint allows you to create and purchase up to 10,000 shipments in a single API request. But its carrier-native multi-piece shipment path tells a different story. Using UPS, you can request rates for up to 50 parcels in a single shipment, purchase labels for up to 40 parcels, and up to 200 parcels using an extended multi-piece shipment, and using FedEx, sending more than 12 parcels within one shipment may result in a timeout. That FedEx figure is not a documented hard cap, it's an observed failure mode, and it matters more in practice than the advertised 10,000-shipment batch number. EasyPost takes the opposite approach to documentation: rather than a hard reject, it is recommended to keep each batch under 1,000 shipments, as this best practice helps avoid timeout errors during the batch buying process. Easyship, by contrast, enforces a schema-level constraint: its batch labels endpoint defines the shipments array with a length between 1 and 1000. Sendcloud splits the difference by endpoint mode, where sync announcements allow a max of 15 parcels per shipment, async announcements allow max 50 parcels per shipment, and each carrier can have a lower limit than the max.

Table 2: customs line-item limits, a separate and often-missed cap

A batch shipment limit and a customs line-item limit are two different ceilings that fail independently. A single SKU-heavy B2B order can blow past the second even when it's nowhere near the first.

USPS has a limit of 30 line items in a customs form, which is the tightest of any carrier checked, while on the other end DHL Express offers the highest capacity by a significant margin, supporting up to 999 line items through the MyDHL API. FedEx sits in the middle on both its REST and SOAP interfaces, and DHL's eCommerce products (distinct from DHL Express) share the same 99-item ceiling across both their Europe and Americas APIs.

What breaks when you treat these as one number

The architectural risk isn't the limit itself, it's assuming one shared ceiling across carriers in a routing table. A platform that validates against FedEx's 99-item commodities array will silently truncate or reject a UPS shipment at item 51, because UPS's Product array maxItems is set to 50. If your adapter builds one schema assumption for "customs line items" across a multi-tenant routing layer, you need per-carrier validation before submission, not a single shared constant.

The same logic applies to package counts. Sendcloud's own documentation is explicit that carrier-specific limits can sit below the endpoint's advertised ceiling, and Shippo's FedEx timeout above 12 parcels shows that a documented number (40) and an observed safe number (12) can differ by more than 3x. If you naively submit a 2,000-line order to a 99-item FedEx array, or a 60-parcel shipment through a 50-item UPS Product array, you need deterministic chunk IDs and a chunk-level idempotency key, not a shipment-level one. A retry on a partially-chunked batch without that granularity re-submits packages that already got labels, which is a worse failure than a clean 4xx.

Designing your own internal ceiling

Set your platform's publish batch size to the lowest common denominator among the carriers active in a given tenant's routing table, not the highest vendor's number. A tenant routing to USPS, UPS, and DHL Express should chunk at USPS's line-item limit of 30, even though DHL Express tolerates 999, because the same order payload often needs to fail over between carriers without a schema rewrite.

It's also worth treating a published hard number as a trust signal in its own right. Several vendors in this comparison, Shippo, Easyship, and FedEx's own Open Ship API, publish an exact figure you can design against. Others, including Cargoson, describe only "reasonable rate limits" without a fixed per-call ceiling, which pushes the burden of discovery onto integrators running their own load tests. If you're evaluating multi-carrier platforms for a tenant with unpredictable label-storm traffic, ask for the number before you sign, not after the first sales peak.

Checklist for capacity planning

• Know your tightest carrier cap across both shipment batch size and customs line items, not just the loosest one you've seen in a sales deck.
• Chunk before you hit the documented ceiling, and chunk at the carrier-specific limit, not a global platform default.
• Treat silent truncation or timeout (like Shippo's observed 12-parcel FedEx threshold) as a failure mode equal to a hard 4xx, not a softer edge case.
• Use chunk-level idempotency keys, not shipment-level ones, so a retried batch doesn't duplicate labels already purchased in a prior chunk.
• Re-check vendor docs quarterly. None of these ceilings are versioned, and several (EasyPost's "recommended" limit especially) can shift without a changelog entry.