Shipping Carrier Integration: How Labels Flow From Your Warehouse System

The short answer: a carrier integration is a request and a reply. The warehouse system sends the carrier who is paying, where the parcel goes, how heavy and how big it is, and which service you want; the carrier sends back a tracking number and a label image. Rate shopping happens before it and tracking after it, but the label request is the core.

The label is the start of the carrier's process, not the end of yours. The price on the label is a quote based on your numbers, the carrier can measure the box again and correct the bill, and a label that never ships may still be charged unless it is voided or refunded inside the carrier's window. This guide follows a label from the pack station to the invoice, using the carriers' own documentation.

What does a carrier integration actually do?

It replaces typing. Without one, someone keys each address into a carrier website, weighs the box, picks a service and prints. With one, the warehouse system already knows the order, the address and the carton, so it sends the request itself and prints the reply on the station's label printer.

Most integrations do four jobs: create the label, group the day's labels for pickup, void labels that will not ship, and bring tracking events back to the order. The pick, pack and ship steps feed all four. If the pack step does not capture the real weight and carton, the integration sends the carrier a guess.

What does the warehouse send to get a label?

The request is mostly data the warehouse already holds. FedEx's Ship API documentation lists among its request elements the "Account Number – The FedEx shipping account number.", shipper information, recipient information, "Service Type", "Packaging Type", "Pickup Type" and "Individual Package Weights." The new USPS Labels API asks for payment details as well, with fields named "Account Type," "Account Number," and "Permit ZIP Code", and USPS states that "An OAuth Token must be generated to call all APIs."

Dimensions are the field most likely to cost money when they are wrong. FedEx charges "based on the dimensional weight or actual weight of the package—whichever is greater," and its dimensional divisor is 139 for US shipments, with each measurement rounded "to the nearest whole inch." FedEx's developer best-practice guide adds a detail that bites integrations: dimensions sent through the API "do not support decimals." DHL Express's API says "there is no need to provide dimensions when the relevant package type code is given."

Two habits keep the request clean:

1. Weigh and measure the packed carton, not the product. The product master knows what the item weighs; only the scale knows what the box weighs with packaging and void fill. UPS tells shippers to use a standard scale and "round up any fraction of a pound."
2. Store each carton size as a record with its outside dimensions, as the carrier will measure them. Then the packer picks a carton and the system sends its dimensions instead of someone typing them.

What comes back, and what prints?

A tracking number and a label image. FedEx's documentation says the response provides "the tracking number and label information," and its image types include "ZPLII" and "EPL2", two thermal printer languages, on stock such as "4'' x 6''". UPS says "Ups.com (including CampusShip) is compatible with most thermal label printers that will print 4" x 6" labels," and that "Standard desktop laser and inkjet printers are also supported." DHL Express's API notes that "PDF Labels rendered can be requested to fit to A4 page size." The USPS migration guide tells developers that the label comes back encoded and "you will need to decode the Label Image."

On the floor this means one practical choice: send labels to a thermal printer in its own language, so the station prints the moment the reply arrives, rather than rendering a PDF and printing it through a desktop dialog.

Is the rate on the label the final price?

No. The rate you see when the label is created is calculated from the weight, dimensions and address you sent. The carrier gets its own measurement later.

UPS says so plainly on its support pages: "Incorrect Weight shipping charge corrections occur when the weight of a package is different than the weight indicated," and it tells shippers to "Avoid Dimensional Weight shipping charge corrections by indicating correct package dimensions" and to avoid residential delivery corrections by selecting "Residential Address." UPS's 2026 Tariff/Terms of Service include a section titled "Shipping Charge Corrections; Audit Fee" and say UPS may determine package data "for invoice purposes, up to and including maximum size and weight." FedEx's January 2026 conditions of carriage for the UK say "FedEx may audit" each air waybill, including "Shipment/Package actual and/or dimensional weight," and "may make adjustments to the invoice"; FedEx's US terms may word this differently, so treat the quoted clause as the UK text.

The consequence for the warehouse is our reading, not a carrier statement: a carrier integration does not make shipping costs accurate by itself. It moves the moment of error. A wrong carton record or an uncalibrated scale used to produce one bad label; connected to an API, it produces a bad quote on every parcel, and the difference arrives later as an invoice adjustment that nobody ties back to the station. The fix is upstream: carton records with real dimensions, a scale that is checked, and a monthly look at the carrier's corrections by carton size.

Address data works the same way. Carriers offer validation. USPS describes its Addresses API as one that "validates and corrects address information," and UPS's address tool can "Classify addresses as either residential or commercial." But FedEx's developer guidance says "FedEx provides Address Validation as a suggestion and not a final determination," and advises: "do not make the shipping process dependent on optional services such as Address Validation." Use validation to flag an order for review, not to rewrite the customer's address silently.

What happens to a label that never ships?

It needs to be voided or refunded inside the carrier's window. Orders get cancelled after packing, a label prints badly and is reprinted, a carton gets repacked. Each of those leaves an unused label behind.

The carriers set different windows. UPS: "If more than 90 days have passed since you created your label, you must contact UPS to request a void," and "A void will not be processed after 180 days." USPS refunds for unused postage are a request, not automatic: under the Domestic Mail Manual, users of postage evidencing systems "must submit requests within 60 days of the date(s) shown in the indicia," and USPS's own Click-N-Ship refunds cover only "Labels that have not been scanned." FedEx's Ship API offers a cancel call for a created shipment and returns an error for an Express package that has "already been tendered to FedEx"; the page we read gives no time limit.

The floor rule that follows: a reprint voids the old label first, and a cancelled order that was already labelled goes onto a void list the same day, not into the recycling.

What is end-of-day close, and do you need it?

Close groups the day's labels; USPS calls its version a SCAN form and FedEx calls its version End of Day Close. USPS's SCAN form, PS Form 5630, "links all the packages in the shipment to one barcode," and when it is scanned "every package in the shipment receives an 'Acceptance' event." USPS adds two rules worth building in: "Labels that have been canceled or already manifested are not eligible to be added to a SCAN Form," and its newer API links labels "through one Electronic File Number (EFN)."

FedEx Ground close is optional for most shippers. FedEx's own documentation says the Ground End of Day Close API "is only required if shipping ground hazmat or if you want to print the manifest report," and that "Close is optional, but recommended." Its best-practice guide still says to close "at the end of the shipping day before the shipment is picked up." If you ship ground hazmat, close is not optional; if you do not, close is how you get a manifest to check against what actually left the dock.

Which carrier API changes should you check?

Three that a warehouse is likely to touch:

USPS lists Web Tools as retired from January 25, 2026 but gives no hard cutoff, and FedEx gives only the maintenance-only date. Neither is permission to wait. If your label printing still runs on an integration built several years ago, ask whoever maintains it which API it calls.

How do you set the label flow up on the floor?

1. Carton records first. Every box you use, with outside dimensions and empty weight.
2. Scale at every pack station, read by the system, not typed.
3. One printer per station, thermal, set to the language the carrier returns.
4. Address flags, not rewrites. Validation failures go to a review queue.
5. Void on reprint and on cancel, inside the carrier's window.
6. Close or manifest daily, and compare it with what the driver took.
7. Review corrections monthly by carton and service, and fix the record that caused them. Corrections per hundred parcels is a fair addition to your warehouse KPIs.

None of this needs a new system to start. It needs the warehouse to treat the label request as data it is responsible for, because the carrier will check it.