Back to Blog
Engineering26 October 20266 min read · 1,323 words

Which Ecommerce Shipping Software Fits Your Order Volume?

N7

No7 Engineering Team

Growth Architecture Unit

Engineering: Which Ecommerce Shipping Software Fits Your Order Volume? (illustration)

Ecommerce shipping software is the integration layer that calculates carrier rates, purchases postage labels, and normalises package tracking states across multiple logistics providers. A store that packs orders by hand at a bench is usually better served by a UI platform with packing screens, while a store whose labels must print automatically from a warehouse system needs a shipping API wired into its backend.

UI shipping platforms versus shipping APIs

UI shipping platforms give packing staff screens to weigh, select a service and print, whereas shipping APIs put label purchase inside your store backend or warehouse management system.

Through the ShipStation OpenAPI, teams calculate and compare shipping rates for carriers connected to their account. ShipStation's API also exposes a rate shopping endpoint that returns a list of rate quotes based on shipment details and rate options.

For stores calculating storefront rates at checkout, our guide on BigCommerce carrier rate architecture covers checkout quote calculation before an order reaches warehouse fulfilment. For UK carriers specifically, see our guide to Royal Mail, Evri and DPD integration with Shopify.

How ecommerce shipping software handles rating and label purchasing

With EasyPost, a one-call buy creates a shipment and purchases a label in a single POST /shipments request. The Luma One-Call Buy endpoint, POST /shipments/luma, goes further: it performs live rating, transit time prediction, rate shopping, and label purchase in a single call. Executing this request requires to_address, from_address, parcel, carrier_accounts, ruleset_name, and planned_ship_date. The carrier_accounts field limits the carrier account IDs for rating consideration, so list every account you want Luma to compare. By default the label comes back base64-encoded; setting persist_label to true instructs EasyPost to return an S3 link to a PNG label image. To book a carrier collection, the application sends a POST request to /pickups/:id/buy with carrier and service parameters.

In Shippo, buying a label means creating a transaction for a shipment using a selected rate. Engineers can include a metadata string when calling the transactions endpoint to associate custom data with the resulting transaction object. If you plan to reconcile dispatches through the API, keep your own copy: Shippo notes that shipment objects older than 390 days are not returned.

In the ShipEngine-based API that ShipStation documents, GET /v1/labels returns labels 25 at a time, starting with those most recently created, so a reconciliation job has to page through results.

Tracking webhooks and normalising carrier status payloads

Tracking architectures must normalise inconsistent carrier event names into standard state machines that customer notification services and order management systems can process reliably.

The EasyPost API creates a standalone Tracker by POSTing to /v2/trackers with a tracking_code and optional carrier. Leave it out and the carrier will get auto-detected if none is provided. Trackers are immutable and duplicates within three months return the original, so a retried create call is safe. Use it when shipping labels are purchased outside of EasyPost and EasyPost is used solely for parcel tracking. EasyPost's tracking guide says the top-level status field on the Tracker is the most reliable indicator for business logic. For hybrid carriers, tracker.carrier_detail.alternate_identifier may appear if available.

Shippo's register-a-tracking-webhook endpoint creates a webhook that will send HTTP notifications to you when the status of your tracked package changes. For live events, you must first create a webhook with the event type set to Track Updated and the environment set to Production. Failed-delivery and return events can then feed your returns process; our guide to Shopify returns and RMA integration architecture covers restocking and replacement orders.

How do Shopify fulfilment orders map to warehouse dispatches?

Shopify keeps the customer's order separate from the work of shipping it: fulfilment orders record where goods ship from, in how many parts, and when. In the Admin GraphQL API, each FulfillmentOrder carries an assignedLocation: the location where the fulfilment is expected to happen. When an order is scheduled for later release, as with a recurring subscription order, the scheduled fulfilment order is automatically transitioned to open when the fulfillAt date and time is reached.

On the order itself, each fulfilment order groups line items that are fulfilled together, allowing an order to be processed in parts if needed. When querying fulfilment orders on an order, setting the displayable argument to true excludes fulfilment orders that are normally hidden from the merchant, such as those closed after being combined or moved. If your store routes dropship lines alongside internal inventory, our analysis of scaling dropshipping on Shopify covers where app-based split fulfilment breaks down as volume grows. An API integration that buys labels for Shopify orders should read fulfilment orders, not the order, so each part ships from its assigned location.

How order volume changes the choice

Order volume matters through what it does to your packing benches, not through a fixed number. Take two figures from your own data: labels needed per hour at your busiest peak, and labels one packer can weigh, pack and print per hour on your current setup. While peak demand stays within what your staffed benches can absorb, a UI platform keeps a person in control of every parcel. When peak demand outruns the benches, or labels have to print from a WMS or conveyor scan with no one clicking, label purchase has to move into code through a shipping API.

Decision framework for picking a shipping model

The choice turns on who touches each parcel and what has to happen without them. Work through these checks:

  1. Measure peak dispatch against bench capacity: Use the two figures from the section above; a sustained gap is the signal to automate label purchase.
  2. Assess warehouse interaction models: Determine whether dispatch staff require visual packing screens and physical barcode scale peripherals, or if pick-and-pack lists originate from a dedicated warehouse management system.
  3. Audit rate shopping requirements: Review whether carrier selection follows simple weight-based tiers or dynamic transit-time optimisation across negotiated commercial carrier accounts.
  4. Map tracking payload destinations: Identify whether parcel updates merely notify buyers via email or trigger automated inventory transitions, invoice reconciliation, and returns processing.
  5. Calculate development and maintenance overhead: Compare each option's published pricing with the engineering time needed to build the integration and keep it working as vendor schemas change.

Under a UI platform model, the operator prints packing slips, weighs parcels manually, and generates carrier manifests directly from an administrative interface. Under a shipping API model, the merchant's warehouse system calls a multi-carrier API such as EasyPost or Shippo, which shops rates and returns a label when a parcel is scanned, with no one typing data in.

Shipping Architecture Comparison

FeatureUI Platform ModelShipping API Model
Operator InterfaceWeb dashboard and packing screens for staffHeadless; integrated into custom WMS or ERP
Rate ShoppingRules and presets set in the dashboardProgrammatic evaluation per shipment payload
Label PurchaseBatches or single labels printed by staffSynchronous one-call buy or rate-then-transact
Tracking IntegrationCustomer notifications sent from the platformInbound webhooks updating internal order state
Best FitPeak volume your packing benches can absorbPeak volume beyond bench capacity, or labels printed with no one clicking

What to do next

Audit your current fulfilment pipeline by mapping the exact point where orders transition from checkout to warehouse packing benches. Identify whether dispatch errors originate from manual carrier selection, slow label printing queues, or inconsistent tracking event ingestion across carrier services.

If your store is outgrowing manual label generation or struggling with multi-location routing across ERPs and logistics networks, scoping custom middleware is the next step. We build custom Shopify integrations that connect your WMS to a shipping API, shop rates across your own carrier accounts and write tracking back to Shopify orders through the Admin GraphQL API. Before you commit, list your carrier accounts, record your standard box sizes and measure labels per hour at your busiest peak.

Frequently Asked Questions

The questions buyers and engineers ask us most about this topic.

When does a shipping API make sense over a UI platform?

A shipping API makes sense when peak orders outrun what your packing benches can handle, when labels must print from a WMS or conveyor scan without anyone clicking, or when routing rules split one order across locations. A UI platform stays the better fit while staff pack and print every parcel and no developers are available to maintain an integration.

What is the difference between a one-call buy and a two-step shipping transaction?

A one-call buy performs rating and purchases the postage label in a single HTTP request, minimising network round-trips for automated queues. A two-step sequence retrieves rate quotes first, allowing business logic or human operators to select an optimal carrier service before creating the transaction.

How does Shopify Admin GraphQL represent split multi-location fulfilment?

Shopify uses FulfillmentOrder objects to group line items fulfilled from specific assigned locations. Each fulfilment order tracks its own routing state, permitting an order to be fulfilled in separate parts and scheduled for release through its fulfillAt field.