FedEx Freight API Integration: A Practical Guide

A FedEx freight API integration connects your ERP, warehouse or order system directly to FedEx's REST APIs, so rate quotes, shipments, labels, bills of lading, pickups and tracking move automatically instead of being typed into a portal. Every version of it does the same five jobs: authenticate with OAuth 2.0, validate the address, rate, ship, and track. Then it writes the results back to your system of record. For less-than-truckload (LTL) shipments, the Freight LTL API adds freight class, handling units, bills of lading and pickup scheduling on top of the parcel flow.

What a FedEx integration actually involves

The API calls are the easy part. The work is in the plumbing around them:

• Data mapping. Turning an ERP sales order or pick ticket into a FedEx shipment request: ship-from and ship-to, packages or handling units, weights, dimensions, service type, payment terms, references and, for LTL, freight class and commodity descriptions.
• Orchestration. When to rate, when to ship, and what happens when a call fails halfway.
• Documents. Getting labels and bills of lading to the right printer in the right format, and keeping a copy.
• Write-back. Putting tracking numbers, carrier charges and status events back on the order, the invoice and the customer notification.
• Operations. Token management, rate limits, logging, alerting and a clear path for a warehouse user when something rejects.

That is standard API and backend integration work, and it succeeds or fails on how carefully the edges are handled.

Which FedEx APIs you need

FedEx publishes its APIs on the FedEx Developer Portal (developer.fedex.com). You enable the ones you need on a project, and that project issues your API key and secret. Most shipping integrations use a subset of these:

Job	FedEx API	Notes
Get an access token	Authorization (OAuth 2.0)	Client credentials grant; tokens are valid for one hour.
Clean up addresses before shipping	Address Validation	Catches bad addresses before they become correction charges or failed deliveries.
Quote parcel shipments	Rate and Transit Times	Account-specific rates and time in transit.
Create parcel shipments and labels	Ship	Create, validate, cancel, and retrieve asynchronous results.
Build shipments over time	Open Ship	For shipments assembled in stages, such as large multi-piece orders.
Quote, ship and pick up LTL	Freight LTL	Rate, ship (labels and BOL), pickup availability, create and cancel pickup.
Schedule parcel pickups	Pickup	Parcel pickup requests and cancellations.
Pull tracking status	Track (Basic Integrated Visibility)	Up to 30 tracking numbers per request. Also tracks by reference, including BOL numbers.
Receive tracking pushes	Shipment Visibility webhooks (Advanced Integrated Visibility)	Near real-time event pushes to your endpoint. Check eligibility and coverage for your accounts.

Authentication and environments

FedEx REST APIs use OAuth 2.0. You send your project's API key and secret to the token endpoint and get back a bearer token, and every subsequent call carries that token. The standard grant type for a shipper calling on its own accounts is client_credentials. Integrator providers who act on behalf of other shippers use different grant types (csp_credentials, client_pc_credentials) and customer-level child keys.

POST https://<FEDEX_API_HOST>/oauth/token
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
&client_id=<YOUR_PROJECT_API_KEY>
&client_secret=<YOUR_PROJECT_SECRET_KEY>

# Response (shape)
{
  "access_token": "<TOKEN>",
  "token_type": "bearer",
  "expires_in": 3600
}

# Subsequent API calls
Authorization: Bearer <TOKEN>
Content-Type: application/json
x-customer-transaction-id: <YOUR_CORRELATION_ID>

Three things matter in practice:

1. Cache the token. Tokens last 3,600 seconds. Request one, share it across workers, and refresh it shortly before expiry. FedEx applies IP-level thresholds to token generation (a burst of 3 requests per second sustained over 5 seconds, or an average of 1 per second over 2 minutes), and breaching them returns 403 Forbidden for 10 minutes. An integration that fetches a token per request will hit this under load.
2. Sandbox is not production. The test environment (apis-sandbox.fedex.com) uses separate credentials, and some responses are virtualized: predefined, not always sensitive to your input. Use it to prove request structure, not rates or transit times.
3. Production needs validation. Moving a project to production issues production keys, but some APIs, notably label-producing ones, require certification first. You generate test labels, submit them to FedEx's label evaluation team, and wait for approval before production labels are authorized. It is a common reason go-live slips.

FedEx Freight LTL specifics

LTL is where generic FedEx integration code falls short: parcel thinks in packages, freight in handling units, classes and appointments.

Freight class and NMFC

Each line item on an LTL shipment carries a freight class (for example CLASS_050) and, where required, an NMFC item. Class drives the freight charge, so it must come from product master data, not the dock. The NMFTA's Docket 2025-1, effective July 19, 2025, moved many commodities to density-based classification on a 13-tier density scale. If your ERP stores a static class per item, check it against current NMFC rules. For density-based items, you may need to calculate class from actual weight and dimensions at ship time.

Handling units and multi-piece shipments

A Freight LTL shipment is made of line items (commodity, class, weight, pieces) and handling units (the pallets or crates FedEx actually moves). The Freight LTL API generates a label for each handling unit. On a multi-piece shipment, the first unit gets the master tracking number and each additional unit gets a child label. FedEx documents limits of 200 handling units when labels are printed one at a time and 40 when all are printed at once, so design your label flow around the larger loads you ship.

Bills of lading and documents

The ship operation returns handling-unit labels and, where required, a bill of lading. It can also return commercial invoices and Canadian customs invoices for cross-border freight. Store the BOL with the order; customers, the dock and freight audit will all ask for it.

Accounts, services and pickup

Requests reference your FedEx Freight account number and that account's billing address, which may differ from the physical ship-from location. Services include FedEx Freight Priority and FedEx Freight Economy, plus options such as FedEx Freight Direct for delivery-appointment service. Pickups are a separate step: check pickup availability for the origin, then create (or cancel) the pickup. A shipment created but never picked up is a common, quiet failure, so keep that step visible.

Freight tracking

The Track API supports tracking by reference, including bill of lading numbers, as well as by tracking number. For push-based updates, FedEx's Advanced Integrated Visibility webhooks list FedEx Ground, Ground Economy and Express as supported. Confirm freight coverage for your accounts before you design around webhooks for LTL, and plan on polling as the fallback.

ERP integration patterns: SYSPRO, Epicor Prophet 21, Access Dimensions and others

ERP shipping integrations almost always follow the same pattern. Don't wire FedEx calls into ERP customizations. Put a small integration service between the ERP and FedEx. The ERP stays the system of record, and the service owns carrier logic, credentials, retries and documents.

1. Trigger. An order reaches a ship-ready state (picked, packed, dispatch note released). The service picks it up through the ERP's API, an outbound event, or a staging table it polls.
2. Enrich and validate. The service pulls ship-to, item weights, dimensions and freight class. It runs address validation and applies packing or palletization rules.
3. Rate (optional). It quotes parcel or LTL options and applies routing rules: cheapest service meeting the promised date, LTL above a weight threshold, and so on.
4. Ship. It creates the shipment through Ship or Freight LTL and receives labels, the BOL and tracking numbers.
5. Print and store. Labels go to the station's thermal or laser printer. Label and BOL images are stored against the order.
6. Write back. Tracking numbers, carrier charges, service and ship date go back to the ERP shipment or dispatch record, and freight charges go to the invoice if you bill them through.
7. Track. Webhooks or scheduled polling update status and delivery confirmation, which can drive customer notifications and close out the order.

SYSPRO

The service reads dispatch or sales order data through SYSPRO's supported interfaces and writes tracking and freight values back the same way, never directly into tables. The key decision is which SYSPRO event counts as "ready to ship," because it determines whether you rate at order entry, at dispatch, or both.

Epicor Prophet 21

Prophet 21 distributors often ship mixed parcel and LTL from one warehouse. The service reads pick tickets through P21's supported APIs, chooses parcel or Freight LTL by weight, cube or item flags, and posts tracking and freight back so invoicing reflects the real carrier charge. Keeping carrier logic outside P21 customizations keeps upgrades uneventful.

Access Dimensions and Sage-family ERPs

Same pattern: detect despatch-ready orders, build the FedEx request in the service, write consignment references and charges back. These systems are often on-premises, so the service runs close to the ERP or connects through a secure agent rather than exposing the ERP to the internet.

Other ERPs, WMS and ecommerce

NetSuite, Dynamics, Acumatica, a WMS or a storefront fit the same shape; only the trigger and write-back target change. The FedEx side gets built once, and each new source system is just another adapter.

Production concerns

• Rate limits. FedEx documents a per-project limit of 1,400 transactions per 10 seconds and daily quotas per organization and per capability. The default Track quota is 100,000 requests per day per project. Exceeding them returns 429. Batch tracking requests (30 numbers per call), back off on 429s, and don't poll delivered shipments.
• Retries and idempotency. Retrying a rate or track call is harmless. Retrying a ship call is not, because a timeout can mean the shipment was created and you never saw the response. Record your own shipment ID and correlation ID before calling. On an ambiguous failure, reconcile before you retry, and use the cancel operation to void duplicates.
• Label storage. Keep every label and BOL in object storage, keyed by order and tracking number, so reprints never mean re-shipping. Pick the label format per station: FedEx supports PDF and PNG for laser printers and ZPLII and EPL2 for thermal printers.
• Address validation. Validate addresses at order entry where you can, not only at the dock, so customer service fixes them before the warehouse is holding a pallet.
• Monitoring. Log each request and response with the order ID and x-customer-transaction-id. Alert on error rates, token failures and shipments with no pickup.
• Failover and multi-carrier abstraction. Put FedEx behind an internal carrier interface (rate, ship, void, track, pickup). When FedEx is degraded, or another carrier rates a lane better, you can route to another carrier without touching the ERP. As volumes grow, this is where scaling work pays off: queues, worker pools and caching around the carrier layer.

Migrating off legacy FedEx Web Services (SOAP)

FedEx's legacy SOAP-based "FedEx Web Services" have been replaced by the REST APIs. FedEx asked compatible software providers to finish upgrades by March 31, 2026, and customers to complete migration by June 1, 2026. Web Services moved to maintenance-only support on July 1, 2026. FedEx has said general troubleshooting and development support for Web Services is ending and that new capabilities are API-first. If a SOAP integration is still running, it can stop working with little notice and nobody will help you fix it.

Treat the migration as a rewrite of the carrier layer, not a find-and-replace:

• WSDL-generated clients become JSON over HTTPS.
• Legacy key, password and meter credentials become Developer Portal projects with OAuth.
• Request and response structures, enumerations and error formats change, so re-map every field and every error you handle.
• Label-producing flows need certification again under the new project.
• If your code already sits behind a carrier interface, only the adapter changes. If SOAP calls are scattered through ERP customizations, first move them into one service, then migrate.

Build vs buy: multi-carrier platforms or direct integration

Honestly, many teams don't need a custom integration. If you ship mostly parcel, use common services and your ERP or storefront already has a maintained FedEx connector or a multi-carrier shipping platform, buying is usually faster to launch and less to maintain. Those platforms absorb API changes like the SOAP retirement for you.

Direct integration makes sense when:

• LTL is a significant share of volume and you need full control of classes, handling units, BOLs and pickups.
• Your routing, packing or billing rules are specific enough that a generic platform forces workarounds.
• You need shipping data inside your own systems in real time, without a third party in the middle.

A hybrid is common: use a platform for parcel and build a direct Freight LTL integration, or build the carrier abstraction yourself and plug FedEx in directly. When shipping is part of a larger product, such as a customer portal, a quoting tool or a logistics platform, it belongs in the product build rather than bolted on afterward.

FedEx API integration checklist

1. Create the Developer Portal organization and project, and enable only the APIs you need.
2. Clean product master data: weights, dimensions, freight class, NMFC and hazmat flags.
3. Define the ERP trigger event and write-back fields before writing code.
4. Implement shared token caching that respects the token-generation thresholds.
5. Add address validation at order entry and before shipping.
6. Build ship calls with your own idempotency record and cancel-based reconciliation.
7. Choose label formats per station, and store every label and BOL.
8. Implement pickup scheduling for LTL and flag unpicked shipments.
9. Choose tracking: webhooks where eligible, batched polling otherwise.
10. Complete label certification and allow time for the evaluation turnaround.
11. Set up logging with correlation IDs, alerts and a runbook for common rejections, and retire any SOAP code paths.

FAQ

Does FedEx have an API for Freight LTL?

Yes. The FedEx Freight LTL API covers LTL rate quotes and transit times, shipment creation with handling-unit labels and bills of lading, pickup availability, and creating or canceling pickups. It uses the same OAuth 2.0 authentication as FedEx's other REST APIs.

Are the old FedEx Web Services (SOAP) still supported?

No. FedEx set a customer migration deadline of June 1, 2026, and moved Web Services to maintenance-only support on July 1, 2026. New features are only on the REST APIs. Any remaining SOAP integration should be migrated now.

How does FedEx API authentication work?

You create a project on the FedEx Developer Portal to get an API key and secret. You exchange them at the OAuth token endpoint using the client credentials grant and receive a bearer token valid for one hour. Cache and reuse that token, because FedEx throttles excessive token requests.

Can I integrate FedEx with SYSPRO, Epicor Prophet 21 or Access Dimensions?

Yes. The reliable pattern is an integration service between the ERP and FedEx that picks up ship-ready orders, validates, rates and ships through FedEx's APIs, then writes tracking, charges and documents back through the ERP's supported interfaces.

What are FedEx's API rate limits?

FedEx documents a limit of 1,400 transactions per 10 seconds per project, plus daily quotas per organization and per capability. The default Track quota is 100,000 requests per day. Exceeding a limit returns HTTP 429, and FedEx says limits can be adjusted to prevent misuse.

Does FedEx offer tracking webhooks?

Yes. FedEx's Shipment Visibility (Advanced Integrated Visibility) webhooks push near real-time tracking events to your endpoint, subscribed by account number or tracking number. Eligibility and service coverage vary, so confirm them for your accounts and keep the Track API as a polling fallback.

If you are planning a FedEx or multi-carrier integration, or need to get a legacy SOAP integration off borrowed time, start your project with us or write to [email protected]. We will tell you plainly whether to build, buy or combine the two.