Shipping API Integration: Labels, Rates, Tracking, and Fulfillment Data Across Carriers

February 9, 2026

Shipping systems sit at the point where digital orders turn into physical movement. Rates change by carrier and service, labels trigger irreversible actions, and tracking updates arrive asynchronously and unevenly across providers. When shipping data is stitched together with brittle integrations or batch syncs, teams end up with delayed tracking, inconsistent fulfillment states, and limited visibility across carriers.

Shipping API integration exists to solve this problem.

In this guide, we'll explain what a Shipping API actually covers, which objects matter in practice, how shipment and tracking lifecycles behave, how real-time updates are delivered (and where they aren't), and how Unified's Shipping API fits alongside Commerce, Accounting, Payments, and CRM in the broader platform.

Introduction to Shipping API Integrations

Shipping platforms such as ShipStation, Shippo, EasyPost, FedEx, UPS, DHL, USPS, Canada Post, and Sendcloud handle carrier connectivity, label creation, rate shopping, and tracking.

Each platform exposes its own API surface with different assumptions:

• Carrier-native APIs often lack list endpoints or webhook support
• Aggregators normalize some data but still vary by object
• Label creation and voiding rules differ by carrier
• Tracking updates arrive at different cadences

A Shipping API provides a way to standardize logistics data and actions across these systems, without building and maintaining separate integrations for each carrier or aggregator.

What Is a Shipping API?

A Shipping API allows applications to programmatically access and manage shipping and logistics data.

In practice, this includes:

• Creating shipments and return shipments
• Calculating and comparing shipping rates
• Purchasing and managing shipping labels
• Tracking shipments and delivery events
• Retrieving carrier metadata

Shipping APIs focus exclusively on logistics execution and delivery state. They are not systems of record for orders, payments, products, or customers.

Shipping API vs Commerce, Accounting, Payments, and CRM

Unified treats Shipping as one category within a broader Finance & Commerce surface, with explicit boundaries.

• Shipping APIs manage shipments, labels, rates, tracking, and carriers.
• Commerce APIs manage product catalogs, variants, inventory, collections, and locations.
• Accounting APIs manage orders, invoices, bills, ledger entries, and financial reports.
• Payment APIs manage transactions, payouts, refunds, and subscriptions.
• CRM APIs manage contacts, companies, deals, and pipelines.

Shipping often consumes identifiers from Commerce or Accounting (for example, an order ID), but it does not own those records. Any synchronization across categories must be handled intentionally by the application.

Real-Time vs Polling in Shipping Systems

Shipping data behaves very differently depending on the object and provider.

Live Access to Source Platforms

Unified's Shipping API routes each request directly to the connected shipping platform. There is no cached replica or background sync. Reads always reflect the provider's current state, subject to their availability and rate limits.

Event Delivery Is Uneven by Object

Shipping platforms differ widely in event support:

• Some providers emit native webhooks for shipments or tracking
• Others require polling behind the scenes (virtual webhooks)
• Some objects cannot be monitored at all through list or event APIs

Because of this, 'real-time' in shipping almost always means tracking-driven, not shipment-driven.

Core Shipping Data Models (and How They Behave)

Unified normalizes shipping data into a small set of objects. Provider behavior still varies and must be handled defensively.

Shipments

Shipments represent the physical movement of goods.

• Support create, list, retrieve, update, and remove operations (provider-dependent)
• Include from/to addresses, packages, carrier selection, service codes, and pricing
• Carry lifecycle fields such as status, shipped_at, and return indicators

Shipment status typically progresses in one direction:

PENDING → PROCESSING → IN_TRANSIT → DELIVERED or EXCEPTION

Once a shipment is in transit, most real-world updates are delivered via tracking, not shipment updates.

Labels

Labels represent purchased postage.

• Support create, list, retrieve, update, and remove operations (provider-dependent)
• Include label_url, tracking_number, label_cost, and is_voided
• Creating a label usually purchases postage and is often irreversible

Although Unified exposes deletion and voiding endpoints, carrier refund rules still apply. A voided label cannot be un-voided.

Tracking

Tracking objects represent delivery progress.

• Read-only
• Include status, carrier events, estimated delivery, and actual delivery timestamps
• Serve as the primary source of shipment updates

For many providers, tracking is the only object that reliably emits update events.

Rates

Rates represent quoted shipping options.

• Generated on demand
• Read-only snapshots
• Must be regenerated to reflect pricing changes

Rates are not long-lived objects and should not be monitored for updates.

Carriers

Carriers represent shipping services.

• Read-only
• Include name, code, logo, and active status
• Maintained by Unified based on provider availability

Identity and Relationships in Shipping

Shipping objects use provider-scoped identifiers.

• shipment_id identifies a shipment within a shipping provider
• label_id, rate_id, and tracking_id link shipping objects internally
• carrier_id references a shipping carrier

There are two intentional cross-category references:

• order_id may reference a Commerce or Accounting order
• warehouse_location_id may reference a Commerce location

There are no references to:

• Payment transactions
• Accounting invoices or bills
• CRM contacts or companies

Addresses are plain objects, not linked to CRM records.

Updates, Events, and Provider Variability

Native vs Virtual Webhooks

Unified supports:

• Native webhooks when the provider emits events
• Virtual webhooks when Unified polls the provider and emits change events
• Polling using list endpoints and updated_gte where available

Virtual webhooks introduce inherent delay based on polling interval. Free plans poll infrequently; paid plans can poll as often as every minute.

Object-Level Differences

• Tracking is the most consistently updated object
• Shipments may or may not emit events depending on provider
• Labels rarely emit update events
• Rates and carriers do not emit events

Some providers do not expose list endpoints for shipments or labels, which makes polling impossible. In those cases, tracking is the only reliable update mechanism.

Security, Privacy, and Data Handling

Shipping data often contains sensitive information. Unified's architecture minimizes exposure.

Zero-Storage Design

• No shipping data is stored at rest
• Label files are retrieved on demand
• No customer payloads are written to logs
• Requests are stateless and region-aware (US, EU, AU)

PII Considerations

Shipping payloads may include:

• Full sender and recipient addresses
• Names, phone numbers, and emails inside address objects
• Tracking numbers and delivery status
• Customs declarations for international shipments
• Label PDFs containing recipient details

Unified passes this data through without persistence. Applications are responsible for downstream storage, access controls, and compliance.

Common Shipping API Integration Use Cases

Multi-Carrier Fulfillment

Create labels and track shipments across FedEx, UPS, USPS, DHL, and others through one interface.

Rate Shopping

Compare rates across carriers before committing to a shipment.

E-commerce Fulfillment

Turn commerce or accounting orders into shipments and labels.

Returns Management

Generate return shipments and labels tied to original shipments.

Tracking & Notifications

Subscribe to tracking updates to notify customers or update internal systems.

Constraints to Plan For

Shipping systems impose real-world limits:

• Not all objects support events or polling
• Label creation is often irreversible
• Shipment status updates are usually indirect
• Provider feature parity is uneven
• Some carriers expose minimal APIs

These are carrier constraints, not platform limitations.

Build vs Buy Shipping Integrations

Building In-House

• Multiple carrier APIs to maintain
• Inconsistent rate, label, and tracking models
• Provider-specific webhook logic
• Ongoing maintenance as carriers evolve

Using a Unified Shipping API

• One normalized shipping surface
• Live access to source platforms
• Standardized objects for shipments, labels, rates, and tracking
• Centralized authentication and maintenance
• Usage-based pricing aligned with API volume

Best Practices for Shipping Integrations

• Treat tracking as the primary update source
• Expect provider variability
• Use webhooks when available, poll when necessary
• Do not assume label voids emit events
• Keep Shipping distinct from Orders, Payments, and CRM
• Design for one-way lifecycle transitions

Build shipping integrations with realistic expectations

Shipping APIs are inherently inconsistent because carriers are inconsistent.

Unified's Shipping API provides a normalized way to create shipments, purchase labels, compare rates, and track deliveries across providers — without storing shipping data or collapsing category boundaries.

→ Start your 30-day free trial

Test shipping integrations with live carrier data.

→ Book a demo

Walk through fulfillment, returns, and cross-category workflows with the team that built the platform.

FAQ

What is a Shipping API?

An API that allows applications to create labels, calculate rates, track shipments, and manage fulfillment programmatically.

Does the Shipping API handle orders or payments?

No. Orders live in Accounting or Commerce. Payments live in the Payment API.

Are shipping updates real time?

Tracking updates may be delivered via native or virtual webhooks. Other objects often require polling or have no update mechanism.

Can I create return shipments?

Yes. Shipments support return indicators and references to original shipments.

Does the Shipping API store shipping data?

No. Shipping data is never stored at rest.

Which platforms are supported?

Unified supports ShipStation, Shippo, EasyPost, FedEx, UPS, USPS, DHL, Canada Post, Sendcloud, and others.