How to connect shipping carriers to order system

Why this matters

How to connect shipping carriers to order system is mostly about one record: the shipment. When an order is packed, someone needs a label, a tracking number and a delivery status that support can see without opening a carrier portal. If those live in a spreadsheet or a shared inbox, every address change and every failed delivery turns into a manual hunt.

Retyping addresses is where errors start. A transposed ZIP code can send a parcel to the wrong depot, and the order record still says shipped. Carrier APIs can validate an address before you buy the label, but only if your order system sends the address in the first place.

Tracking events matter for support and finance. A delivered scan closes the loop for the customer, a returned to sender scan triggers a refund decision, and an exception scan needs an owner. When events land on the order record, your team can filter open shipments and act on the ones that are stuck.

Shipping cost belongs on the order too. If the label cost and the carrier invoice are disconnected, margin reports drift and claims get missed. Connecting the carrier gives you the label cost at purchase, and a reconciliation step later catches adjustments like address corrections and surcharges.

Before you start

Collect the carrier accounts and the people who own them. Note the account number, the contract or rate card, the service levels you actually sell, and whether labels bill to your account, a third party or the receiver. Some carriers need a meter number or a separate developer key for label purchase, so ask before you build.

Decide where the shipment record will live. Your order system is the natural owner, but some teams keep a separate shipping service for rate shopping and label printing. Pick one owner for the tracking number and one owner for the label cost, then write it down.

Check your order data for the fields carriers demand: street address lines, city, state or province, postal code, country, phone, email, item weight, package dimensions, declared value and a reference number. Carriers reject labels for missing phone numbers on international shipments and for boxes over the size limit.

You need a public HTTPS endpoint for carrier webhooks and a place to store label files and raw event payloads. Get sandbox credentials for each carrier, and confirm whether the sandbox sends real tracking events or only synthetic ones. That changes how you test.

How to do it

Start with one carrier and one service level. Buy a label in sandbox, print it, void it, and trace every record it touches in your order system. That small loop shows you where field mapping breaks before you add more carriers.

Choose between direct carrier APIs and a multi-carrier aggregator. Direct APIs keep you close to carrier features like signature options, Saturday delivery and commercial invoices, but each carrier has its own auth flow and error codes. An aggregator gives you one API and one label format across carriers, and it usually takes a fee or a markup on each label. For low volume, the aggregator is often faster to ship. For high volume or negotiated rates, direct can pay off.

Build the sync as a state machine, not a single call. An order moves from ready to rate selected, label purchased, in transit, delivered or exception. Each transition writes a record and can be retried safely. Keep the carrier response body so you can debug a rejection without guessing.

Tracking events arrive by webhook, but also build a polling job as a safety net. Webhooks get missed during deploys, and carriers retry on their own schedule. A nightly poll of open shipments catches the gaps.

1. List carriers, accounts and services. Write down every carrier account, the service levels you sell, and who owns the credentials. Note which accounts are prepaid, which bill to a third party, and which need a meter number or account specific setup.
2. Choose direct APIs or an aggregator. Direct carrier APIs give you full control of features and rates, but each carrier has its own auth, label format and error codes. An aggregator gives you one API for many carriers and takes a fee or markup, so check the commercial terms.
3. Design the shipment records first. Add shipment, package and tracking event records to your order system. Store the carrier, service, label id, tracking number, weight, dimensions, cost and current status on the shipment, and keep every scan event with a timestamp.
4. Map order fields to carrier fields. Map address fields, contact phone, item weight and dimensions, declared value and reference numbers. Validate addresses before you buy a label, and decide what happens when a carrier rejects an address or a PO box.
5. Build label purchase with idempotency. Send a unique idempotency key with each label request so a retry cannot buy two labels. Handle rate expiry, auth token refresh and carrier errors with a retry queue and a dead letter queue for rejects.
6. Receive tracking events through a signed webhook. Expose an HTTPS endpoint, verify the carrier signature, and store the raw payload plus a normalized status. Return a success response fast, then process asynchronously so the carrier does not retry forever.
7. Test void, return and exception flows. Void a label in sandbox and confirm the order record clears the tracking number and marks the label voided. Simulate address correction, refused delivery and lost package events, and check that your support team sees the right next action.
8. Go live one carrier at a time. Start with your highest volume carrier and a single service level, then add carriers once the events land cleanly. Keep manual label purchase available as a fallback during the first week.
9. Add a reconciliation job. Poll open shipments once a day and compare the carrier status with your stored status. Log any mismatch and send an alert when a shipment has no event after its expected pickup window.

How to check it worked

Run a test order through the full path: quote, label, print, void, rebuy. Confirm the order record shows the carrier, service, tracking number, label cost and status at each step. Then open the carrier portal and compare the tracking number and service code, not just the status label.

Send duplicate webhook payloads and confirm you store one event, not two. Replay an old event and check that it cannot move a delivered shipment back to in transit. This catches missing idempotency and out of order event handling.

Check the end of day manifest or scan form against the labels you bought, and void any label that will not ship. An unvoided label can still appear on the carrier invoice even if the package never moved.

Test the failure paths: invalid address, expired rate, rejected label, carrier timeout and a webhook with a bad signature. Each one should create an alert or a task with the order number and the carrier error code. Watch the first week of real shipments before you turn off manual label purchase.

Mistakes to avoid

Buying a label without an idempotency key is the classic mistake. A timeout or a double click can create two labels and two charges, and voiding one does not always remove the charge. Use a client generated key per order and package, and make the carrier call safe to retry.

Do not trust the carrier webhook without verifying the signature. Anyone can post a fake delivered event to your endpoint if it is public. Verify the signature, check the carrier account, and store the raw payload before you normalize it.

Do not collapse every carrier status into shipped. Carriers have different codes for accepted, in transit, out for delivery, delivered, refused, returned and exception. Map them to a small set of internal statuses, but keep the raw code so support can see the detail.

Do not forget returns. A return label is a separate shipment with its own tracking number, cost and status. Link it to the original order and the return authorization, or your team will hunt through two systems when the customer asks where the refund is.

If you would rather not build the connector yourself, one option is the Cloudverg Systems integration build at $12,500/month. It covers an integration map, live integrations with retries, field mapping docs, alerting, backfill and a handover runbook. Compare that with a shipping aggregator, a direct build by your team, or a paid app in your order platform.

Frequently asked questions