Mapping UPS and FedEx API Data to EDI 214

UPS and FedEx don't send you an EDI 214. They never have. Both carriers built their visibility stack around REST APIs and webhook-style push notifications, which means every shipper running a 214-based status pipeline for LTL and FTL freight hits a wall the moment a parcel shipment enters the mix. This is a practical walkthrough for closing that gap: subscribing to UPS Track Alerts and FedEx Track API events, then transforming the JSON into standards-compliant EDI 214 AT7 segments so your TMS, WMS, or ERP sees one event model regardless of carrier.

Why parcel carriers break your EDI 214 pipeline

Freight carriers report shipment status using EDI 214, an ANSI X12 transaction set used to communicate real-time shipment status updates between carriers, shippers, brokers, and consignees that reports milestones such as pickup, in transit, arrival, and delivery using AT7 status codes. EDI 214 is an ANSI ASC X12 transaction set used to communicate real-time shipment status updates between carriers, shippers, brokers, and consignees, reporting milestones such as pickup, in transit, arrival, and delivery using AT7 status codes, enabling automated freight visibility across truck, rail, and intermodal networks. Parcel carriers never joined that pattern. REST APIs are the modern default for new carrier and logistics SaaS connections, JSON-based, well documented, and support both real-time and on-demand exchange. FedEx, UPS, DHL, and most current TMS platforms expose REST endpoints.

The practical pain shows up on the dispatch screen. One carrier's feed says "Out for Delivery," another says "OFD," a third hands you a clean AT7 code of AF. All three mean the same event, but your TMS treats them as three different things unless something normalizes them first. That something is what this guide builds.

What you need before starting

Before touching any code, get these in place. Skipping one of them is the most common reason teams restart this project halfway through.

• A UPS developer account with Track Alerts subscription access and a FedEx developer account with OAuth 2.0 credentials for the Track API
• A test EDI mailbox or AS2 endpoint that can actually receive and parse inbound 214s, not just send them
• A transformation layer: a custom script, an iPaaS tool like Boomi or Celigo, or a TMS with a built-in mapper. Some platforms, including Cargoson, handle parcel-to-EDI normalization natively rather than requiring you to build it from scratch
• A governance matrix listing which AT7 codes your downstream systems already act on, so you're not inventing new codes nobody consumes

Step-by-step: UPS Track Alerts to EDI 214

UPS's push mechanism works through subscription, not constant polling. UPS supports webhook-style tracking notifications for selected events and use cases, with scheduled Tracking API requests available where webhook coverage is incomplete.

1. Register each tracking number with the UPS Track Alerts API, supplying your webhook URL alongside the tracking number at shipment creation. UPS has introduced a Track Alerts API that provides push notifications, and according to UPS, this delivers status updates directly to your subscribed URL.
2. Build a webhook receiver endpoint that accepts the inbound POST, authenticates the source, and validates the payload before anything touches your pipeline. Authenticate the source and validate all inputs so carriers can safely drive updates into your ERP without opening a backdoor.
3. Many teams decouple this from the ERP itself. A common architecture is to decouple the webhook endpoint from the ERP for security and reliability, using a middleware server or an iPaaS tool to handle the webhook, then forward the data via standard APIs.
4. Map the UPS status field to an AT7 code using your lookup table (built in the next section).
5. Populate the B10 segment with the tracking number as the shipment reference and your assigned SCAC-equivalent carrier identifier, then populate MS1 with the scan location pulled from the UPS payload.
6. Generate the 214 and transmit it to your TMS or ERP mailbox exactly as a freight carrier's EDI feed would arrive.

Step-by-step: FedEx Track API to EDI 214

FedEx's flow starts with OAuth token retrieval, then a call to the tracking endpoint for the shipment in question.

1. Authenticate with OAuth 2.0 and call the track-by-tracking-number endpoint. The Tracking API provides the capability of retrieving the detailed transit information for a single FedEx tracking number.
2. Parse the returned statusCode. FedEx's code set includes OC for shipment information sent to FedEx, alongside PU for Picked Up, AF for At FedEx Facility, AR for Arrived at, DP for Departed, and DL for Delivered, plus OD for out for delivery.
3. Map each FedEx code to its matching AT7 value. PU becomes a pickup event, DL becomes a delivery event, and intermediate scans like AR and DP generally roll into transit logging rather than triggering a separate AT7 event, unless your governance matrix says otherwise.
4. FedEx's webhook coverage isn't complete for every service type, so schedule a polling fallback for tracking numbers that haven't received a push event within your expected cadence.
5. Transmit the normalized 214 using the same B10/AT7/MS1 structure as the UPS path, so downstream systems can't tell which carrier originated the event.

Building the AT7 mapping table

This table is the actual deliverable of the project. Get this right and everything downstream works off one model. AT7 status codes cover the full journey: X3 = dispatched, X1 = picked up, AF = out for delivery, D1 = delivered, X6 = delayed, with many carriers supplementing standard codes with their own extensions.

Each row needs the underlying AT7 structure filled correctly or the segment won't parse. AT701 is the shipment status code, AT702 is the reason code, with AT705 carrying the date as CCYYMMDD and AT706 the time in 24-hour format. Miss the date/time pairing rule and your 214 fails validation before it ever reaches the TMS.

Here's what most people miss when they build this the first time: an AT7 code that arrives but isn't mapped to a downstream action is worse than no code at all, because it looks like the integration is working. Poor EDI 214 mapping, where AT7 status codes arrive but do not trigger downstream system updates, is the most common reason supply chain teams still make manual carrier phone calls despite having EDI in place, because the 214 is only as valuable as the automations it triggers. If AR and DP scans aren't tied to anything, that's a deliberate decision, not an oversight.

How to know it worked

Run a test shipment through both carriers end to end before trusting the pipeline with production volume. The sequence that works: upload the sample file to your EDI test mailbox and verify segment-level parsing, with every field visible and correctly labeled, then map each segment to your TMS/WMS/ERP fields, replace the sample tracking numbers with live shipment records, and simulate each AT7 code in isolation to confirm the correct workflow fires. If your receiving system also returns a 997 or 999 functional acknowledgment for freight EDI, confirm the same round-trip works for your transformed parcel 214s. If the ack never comes back, the receiving mailbox is rejecting the envelope structure, not the content.

Failure mode: webhook gaps and out-of-order events

Push notifications are not guaranteed to be complete. UPS supports webhook-style tracking notifications for selected events and use cases, with scheduled Tracking API requests available where webhook coverage is incomplete. FedEx has the same limitation for certain service levels. The fix is a polling job that checks any shipment without a recent event against the Track API directly, with idempotency logic so a retried webhook doesn't fire the same AT7 event twice. Also watch for sequence errors: a delayed webhook can deliver a "Delivered" event before an "Out for Delivery" event arrives, especially across retry queues. Build lifecycle sequencing rules that hold a delivery event until pickup and transit events for that tracking number are already recorded, or reject it for manual review.

Teams that don't want to build and maintain this layer themselves generally go one of two directions. TMS platforms including MercuryGate, Descartes, Transporeon, and Cargoson increasingly normalize carrier status feeds, freight and parcel, into a single event model as part of their connectivity layer. Multi-carrier aggregators like ShipStation, EasyPost, Sendcloud, and AfterShip solve a narrower version of the same problem by unifying tracking statuses across carriers, though you'd still need to convert their output to EDI 214 format if your downstream systems expect it. The limit is coverage: many legacy carriers, especially in the US LTL segment, still have no REST option, so a hybrid pipeline handling both EDI and API sources isn't a temporary stage, it's the permanent architecture for most mid-size and large shippers.

Next steps

Once this mapping and the webhook/polling hybrid work for UPS and FedEx, the same pattern extends directly to DHL, USPS, and regional couriers. The AT7 lookup table doesn't change in structure, only in the source codes you're mapping from. Build it once with clean governance around which codes trigger which automations, and every new parcel carrier becomes a mapping exercise instead of a new integration project.