FedEx vs UPS API for EU-to-US Parcel Labels

Why EU-to-US parcels need their own comparison, not another rate-limit table

Most "FedEx API vs UPS API" content on this blog lives inside bigger rate-limit roundups, where both carriers show up as a row next to DHL, Shippo and ShipEngine. That's useful for a quick scan, but it hides what actually trips up a European shipper building a direct EU→US parcel integration: not raw throughput, but whether you can get a production label approved without a support ticket, and whether tracking updates land in your system as events or as something you have to poll for.

This post scopes down to one job: a European shipper or 3PL building direct-to-carrier label generation, customs documentation and tracking for parcels moving from the EU into the US. Not domestic US. Not freight. Just the parcel label + track path that most mid-sized shippers actually build before they consider a multi-carrier layer.

The criteria, and why each one matters for this specific build

We picked four criteria because they map to the actual cost centers of this integration, not to marketing checklists.

• Auth and rate-limit transparency. If a vendor publishes concrete numbers, you can size your retry queue and token refresh logic before you've written a line of production code. If they don't, you're sizing against guesses and tuning in production.
• Label format and customs/AWB document support. EU→US shipments need a commercial invoice at minimum, and FedEx Express shipments carry an additional documentary requirement that UPS's package flow doesn't mirror in the same way.
• Webhook and event coverage. Polling every tracking number on a schedule is a real infrastructure cost once volume climbs. Native push events remove that cost; subscription-based feeds only partly remove it.
• Certification friction. Time-to-first-sandbox-label is a vanity metric. Time-to-first-production-label is the number that affects your launch date.

FedEx REST API vs UPS API: the comparison table

Everything below comes from each carrier's own developer documentation or an open GitHub issue where the vendor itself left a question unanswered. Where a figure isn't published, the cell says so rather than guessing.

Where FedEx pulls ahead

FedEx is the only one of the two that gives you numbers you can actually design against before you've sent a single production request. Each project has a transaction rate limit of 1,400 transactions per 10 seconds. An organization quota example in FedEx's own docs shows 500,000 API requests per day, and once that's reached, subsequent requests return a 429 until the next day. Per-capability quotas are documented too: if a project has a 100K limit per track capability spanning six endpoints, all six count against that single limit.

Token lifecycle is equally explicit. The OAuth token expires every 60 minutes and has to be regenerated using the authorization endpoint. That's a number you can build a refresh scheduler around on day one, instead of discovering it empirically.

Webhooks are native rather than bolted on, with published caps: each organization profile can create up to 100 webhooks, each account-number-based webhook can carry up to 1,000 account numbers, and tracking-number-based webhooks can include up to 1,000 tracking numbers per request. For a tracking-heavy EU→US flow where you're watching hundreds of parcels clear US customs, that's a real reduction in polling load.

The trade-off is calendar time before launch. Moving a project to production isn't just a key rotation. Shipping labels must be printed and scanned at a minimum of 600 DPI, and files generated directly from the API are explicitly rejected. The Bar Code Analysis group requires a three-business-day turnaround for label evaluation, and if you're shipping FedEx International Express, the label set must also include the auxiliary or secondary Air Waybill label. None of this is hard, but it is a scheduled wait you need to plan around, not something you can route around with good engineering.

Worth flagging: FedEx rolled these quotas out broadly rather than quietly. Starting October 15th, all new FedEx API integrations are subject to transaction quotas and rate limits, though existing projects set up before that date weren't immediately impacted. If your project predates the rollout, check whether you've since been migrated onto the new limits before you assume the old behavior still holds.

Where UPS pulls ahead

UPS has no equivalent public certification gate described in its documentation the way FedEx does, which means if your account team grants production access promptly, you can plausibly reach a live label faster than you would through FedEx's print-and-scan cycle. UPS also supports the customs mechanics you need for EU→US: the Shipping API supports international returns and returns in countries where the API is supported, and negotiated rates are available, though you have to contact your UPS Account Representative to obtain negotiated package rates through the Developer Kit rather than self-serve them.

For tracking, UPS runs on a subscription model rather than FedEx's always-on webhook config. Quantum View subscriptions can include manifest, origin, exception and delivery events, but those subscriptions are created by you through ups.com, not through the API itself, which means part of your onboarding is a portal workflow outside your codebase. UPS does offer something closer to a true webhook in Track Alert: UPS describes it as giving "near real-time event updates", and UPS sends HTTP POST events to your URL for 14 days after you subscribe a tracking number. The catch is cost and scope: Track Alert is a paid offering on the UPS developer portal, layered on top of whatever your base API access already costs.

The real trade-off with UPS is that you're flying without instruments on throttling. An open GitHub issue asked UPS directly: "Are the Rate Limits published for the REST API?" UPS's response pointed developers to email a mailbox with their client ID and desired rate limit for evaluation, rather than pointing to a published number. That issue has sat open since September 2023. Separately, third-party documentation of UPS's limits states plainly that UPS API rate limits are negotiated per contract, with no public defaults published. For a team sizing a retry/backoff strategy before launch, that's a guess dressed up as infrastructure planning.

The verdict for EU-to-US label and tracking builds

Default to FedEx. If you need to size queues, token refresh cycles and backoff logic against real numbers before you write code, FedEx's published quotas, rate limits and webhook caps give you something concrete to engineer against, and its native webhook model cuts polling cost for tracking-heavy flows. That default flips if your production go-live date is the tightest constraint you have: UPS's lack of a formal print-and-scan certification gate can get you to a live label faster, provided your shipment volume is low enough that undocumented rate limits won't bite before you've had a chance to negotiate them with your account rep.

Put differently: pick FedEx when engineering predictability matters more than launch speed, and pick UPS when launch speed matters more than knowing your throttle ceiling in advance. Most EU shippers running meaningful volume into the US will hit the ceiling eventually either way, and at that point you're back to emailing a UPS mailbox or reading FedEx's quota guide line by line.

Teams running both carriers side by side, plus DHL or GLS for EU domestic legs, tend to hit the same two problems twice: normalizing webhook payloads across carriers with different event models, and guessing at rate limits that aren't published anywhere official. That's the gap multi-carrier layers like Cargoson, nShift and Sendcloud exist to absorb, at the cost of a thinner webhook contract than you'd get going direct to either carrier.

What we haven't tested yet

This comparison is built from documentation, not from our own sandbox logs for either carrier's EU→US path specifically. We haven't measured actual UPS throttling behavior under load, real webhook delivery latency for FedEx versus UPS Track Alert, or whether FedEx's quota figures hold steady now that the October 15th rollout has had time to settle into existing projects. That's the natural next step: instrument both sandboxes, send comparable load, and report delivery latency and 429 rates side by side in a future Benchmark Report.