After Sendle: architecting Shopify and WooCommerce shipping so the next carrier failure doesn't crash your store

Quick answer: Sendle shut down across Australia on 11 January 2026, taking thousands of Shopify and WooCommerce stores offline at the label-generation layer for the rest of the working day. The reflexive response — sign up to the next carrier and re-plumb the integration — is the same pattern that produced the outage. A carrier-agnostic shipping layer with rate-shopping, queued label generation, and automatic failover takes one or two extra weeks to build the first time and saves the next outage entirely. This piece walks through the patterns we deploy when we build ecommerce integrations for stores that can’t afford a revenue-zero day.

On the morning of 11 January 2026, every Australian store with Sendle as their default carrier discovered the same problem at roughly the same hour: shipping labels stopped generating. Booked pickups were cancelled silently. The Sendle dashboard returned errors. By the afternoon, the email had landed: Sendle had ceased operations in Australia, effective immediately, after a 2025 merger with US logistics partners failed to secure ongoing funding.

For stores running Shopify or WooCommerce with Sendle as their single carrier integration, the outage was an immediate revenue-zero day. Orders couldn’t ship. Refunds had to be processed manually for items already paid for. Customer-service inboxes filled with “where’s my order” emails the team couldn’t answer with confidence. The carrier-switching work that followed took anywhere from a few hours (for stores already using a multi-carrier abstraction like Starshipit or Shippit) to several weeks (for stores that had built directly against Sendle’s API).

The reflexive fix — the one most of the post-Sendle articles are still recommending — is to pick a replacement carrier (Australia Post via MyPost Business, Aramex, CouriersPlease, Shippit) and re-plumb the integration. That works. It also produces an identical failure mode if any of those carriers exits the market, raises rates beyond what your margins tolerate, or has an extended platform outage.

The pattern worth building instead is carrier-agnostic: a shipping layer that talks to multiple carriers behind a single internal interface, with rate-shopping, automatic failover, and label-generation queueing that survives any single vendor going down. For stores doing real volume, that’s the difference between “Sendle was a bad day” and “Sendle was an existential event.”

Why single-carrier integrations keep failing

Carriers come and go. Sendle is the most recent and most dramatic example, but it isn’t the only one. Across the last decade of Australian ecommerce we’ve seen pricing structures change overnight, regional service areas dropped, API endpoints deprecated with short notice, and acquisitions that materially altered the offering store-owners had built against.

The pattern that produces a revenue-zero day on any of those events:

• One carrier wired directly into the order flow. The Shopify or WooCommerce store has a single carrier integration. When the order is fulfilled, the integration calls the carrier’s API to generate a label. If the carrier is down, the order doesn’t ship.
• Carrier-specific data in the order schema. The order record holds the carrier-issued tracking number, the carrier-specific label PDF, the carrier-specific consignment reference. Switching carriers requires the schema to learn new fields, and historical orders point to a system you no longer have credentials for.
• Customer-facing tracking links pointing at the carrier’s domain. Tracking emails contain https://track.[carrier].com/[reference] links. When the carrier disappears, the links break and customers lose access to their tracking history.
• No fallback queue. If the carrier’s label-generation API is briefly unavailable, the fulfilment flow fails synchronously. The team retries manually. If the unavailability lasts longer, orders stack up.

Each of those is a normal short-cut that ships the integration faster. Together they produce a fragile shipping layer where any vendor change is a same-day fire.

The carrier-agnostic pattern

The pattern that survives is to put a thin internal abstraction between the store and any specific carrier’s API. The abstraction handles:

• Rate shopping. Given an order’s weight, dimensions, origin, and destination, query multiple carriers and select the best fit based on cost, service level, and current availability.
• Label generation behind a queue. When fulfilment triggers, enqueue a label request. A worker picks it up, calls the chosen carrier, persists the label PDF and tracking reference, marks the order shipped. If the carrier’s API is down, the worker retries with exponential backoff and falls back to a secondary carrier after a configurable threshold.
• A normalised tracking schema. The order record stores a carrier-neutral tracking record (carrier code, reference, label URL, status timeline) rather than carrier-specific fields. Switching carriers requires no schema changes.
• Internal tracking redirects. Customer-facing tracking links point at yourstore.com/track/[order] rather than the carrier’s domain. The redirect resolves to the current carrier’s tracking page. When you switch carriers, the customer-facing links keep working.

The abstraction is small — a few hundred lines of code, in our experience — but it changes the failure surface fundamentally. A single carrier going offline becomes a config change, not a re-architecture.

What “rate shopping” actually buys you

The first carrier-agnostic feature most stores discover after building the abstraction is rate shopping — checking multiple carriers at the time the label is generated and selecting the cheapest service level that meets the customer’s shipping expectation.

For a store doing 1,000 orders a month at an average of $11 shipping cost, a 12% saving from rate shopping is $1,320 a month. The integration pays for itself inside the first quarter on most realistic store volumes.

The harder version of rate shopping — the one worth building once the basic version is live — is to surface the rate-shopped result at checkout, not just at fulfilment. The customer sees the carrier and service level that will actually ship their order. This requires the rate-shopping layer to be fast enough to add to the checkout flow (sub-500ms typically), which in turn requires aggressive caching of carrier rate cards and fallback logic for the case where a carrier’s rate API is briefly unavailable. The patterns are the same as those we describe in webhook patterns that don’t fall over — idempotency, queueing, and a reconciliation safety net.

The carriers worth integrating to as your starting set

In our experience, for an Australian store building this layer from scratch in mid-2026, the carrier set worth starting with is:

• Australia Post via either the Australia Post Shipping & Tracking API directly or MyPost Business credentials. Coverage is universal; rates are competitive for small-to-medium parcels; reliability is the highest of any AU carrier. The API itself is more complex than the third-party alternatives, which is the trade-off for going direct.
• Aramex (formerly Fastway) for state-by-state service in metropolitan areas where their courier model beats Australia Post on cost.
• CouriersPlease for metropolitan same-day and next-day where speed beats cost.
• DHL Express for international, particularly Asia-Pacific destinations where Australia Post International isn’t cost-competitive.

For a store starting from zero, integrating to Australia Post alone covers ~80% of realistic shipping needs and gives you a working baseline. The other carriers get added when the volume justifies the rate-shopping work.

Multi-carrier aggregators — Starshipit, Shippit, Easyship, ShipStation — sit at a different layer. Each of them already implements the carrier-agnostic abstraction, with their own rate cards (some of which are competitive, some of which aren’t). For stores doing under ~500 orders a month, paying one of these aggregators is almost always cheaper than building the abstraction yourself. For stores doing 2,000+ orders a month, the math typically flips — the percentage their service takes off your margins exceeds the cost of building and operating your own carrier layer.

The cross-over point depends on the specifics of your shipping mix, your margin structure, and how much carrier-specific business logic you need (special rates negotiated directly, picking-station integration, multi-warehouse fulfilment). Start a project if you want us to model the cost trade-off against your real numbers.

Label generation as a queue, not a synchronous call

The single highest-leverage architectural change for any store running a direct carrier integration is to move label generation off the synchronous fulfilment path and into a queue.

In the fragile pattern:

1. Order is marked “ready to ship” in the admin
2. The integration calls the carrier’s API to generate a label
3. The carrier responds with the label PDF and tracking reference
4. The order is updated and marked shipped
5. The customer is notified

If step 3 fails — carrier API is slow, briefly down, returning a transient error — the fulfilment fails. The admin sees an error. The team retries. If the failure persists, orders stack up.

In the robust pattern:

1. Order is marked “ready to ship”
2. A label-generation job is enqueued
3. The admin returns immediately, showing the order as “queued for shipping”
4. A worker picks up the job, attempts label generation, retries on transient errors, and falls back to a secondary carrier after a configured threshold
5. On success, the order is updated and the customer is notified
6. On terminal failure, the job lands in a dead-letter queue for manual handling

The robust pattern adds a small amount of complexity but removes most of the “carrier is briefly slow and everything backs up” failure mode. It also makes failover between carriers straightforward to implement — the worker tries the primary carrier first, and if the primary fails repeatedly within a time window, switches to the secondary.

The same queue-and-worker pattern shows up in our integration testing work because it’s the same shape: any external dependency that can’t be relied on for synchronous availability should be processed asynchronously, with retries and a dead-letter queue.

Customer-facing tracking links should never point at the carrier’s domain

This is the cheapest pattern to implement and the one most stores skip until they need it.

Every tracking email, every “view tracking” link in the customer account, every shipping confirmation should resolve to a URL on your own domain. Something like https://yourstore.com/track/[order-token] or https://yourstore.com/orders/[order-id]/tracking/.

That internal URL looks up the order’s current carrier and reference, then redirects to (or proxies through) the carrier’s tracking page. When the carrier changes, the customer-facing links keep working — only the redirect needs to update.

For Sendle stores, this would have prevented one of the most painful parts of the January 2026 transition: every tracking link in every previous order confirmation broke at the same moment as the API. Stores that had built the redirect pattern would have updated one config value to point legacy Sendle references at the appropriate tracking destination (or a status page explaining the carrier change). Stores that had baked Sendle’s tracking domain into their emails sent customers to dead URLs for months.

The pattern also gives you the option of building your own tracking page over time — pulling status events from the carrier’s API and rendering them in your own template — which is a noticeably nicer customer experience than the default carrier page on every major Australian carrier.

When the off-the-shelf aggregator is the right answer

Most stores reading this article should not build a carrier-agnostic shipping layer from scratch. The off-the-shelf aggregators — Starshipit and Shippit are the AU market leaders; Easyship and ShipStation have international reach — already implement the patterns above. They handle rate shopping, multi-carrier failover, normalised tracking, and customer-facing tracking pages. For a store doing under several hundred orders a month, paying one of them a per-shipment fee is cheaper than building and operating the abstraction yourself.

The honest indicators that custom is worth the work:

• Order volume is high enough that aggregator fees exceed the build-and-operate cost. Typically this is in the 1,500–3,000 orders/month range, depending on the aggregator’s pricing structure and your average shipping cost.
• You have negotiated direct rates with one or more carriers that the aggregators don’t offer. Direct integration lets you use those rates without paying a margin to the aggregator.
• Your shipping logic doesn’t fit the aggregator’s assumptions. Multi-warehouse fulfilment where the warehouse is selected based on stock + customer location + carrier service area is a common case where aggregators struggle. So is split-shipment for orders containing items from multiple warehouses.
• You’re running an own-fleet operation alongside third-party carriers and want the shipping layer to dispatch to your own drivers for in-zone deliveries and fall back to carriers for out-of-zone.

Any of those, individually, can justify the custom build. None of them are common at small-store scale.

The migration off Sendle specifically

For stores still mid-migration as of mid-2026, the steps that matter:

1. Audit existing tracking links in customer emails, account pages, and CRM records. Identify which currently point at Sendle’s tracking domain and which (better) already use an internal redirect.
2. Choose the carrier set that fits your shipping mix. For most stores moving off Sendle, Australia Post via MyPost Business covers the bulk of the volume, with Aramex or CouriersPlease as the metropolitan-courier supplement.
3. Decide custom vs aggregator based on the volume math above. For most Sendle stores migrating in 2026, an aggregator (Starshipit or Shippit) is the faster path back to shipping.
4. Build the customer-facing tracking redirect as part of the migration, even if the rest of the integration is aggregator-handled. This is the cheapest part of the architecture to make portable and the highest-impact change for the next carrier event.
5. Run reconciliation against the last 90 days of Sendle shipments to identify orders that may have been mid-transit when the shutdown happened. Some of those parcels are still in the system; some are lost. The customer-service load from this alone is meaningful and worth surfacing as a distinct workstream.

The cost of doing this work properly is the difference between Sendle being a bad week and Sendle being a recurring fire for months. We’ve done several of these migrations in 2026 already.

Common questions

How long does a Sendle migration take? For a store on an aggregator (Starshipit, Shippit), the carrier switch is a config change — hours, not days. For a store with Sendle wired directly into Shopify or WooCommerce via a custom integration, expect one to three weeks for a clean re-plumb. The fastest path is usually to deploy an aggregator as the interim solution while the longer-term carrier-agnostic abstraction is being built.

Should I just use Australia Post for everything? For most stores doing under a few thousand orders a month, Australia Post via MyPost Business is the right starting point. It covers universal delivery, rates are competitive, and the API is stable. The case for adding a second carrier is when metropolitan courier services (Aramex, CouriersPlease) beat Australia Post on either cost or speed for a meaningful share of your shipping mix.

What’s the right tracking URL pattern? Internal-domain URLs that resolve to the current carrier’s tracking page via server-side redirect. The shape we deploy is /track/[order-token] or /orders/[order-id]/tracking/ — the token-based pattern is preferable because it doesn’t leak the internal order ID and works without authentication. The redirect resolves to whatever tracking URL the current carrier exposes.

How do I handle the customer-service load from the Sendle shutdown? A few patterns help: a dedicated page on your domain explaining the carrier change with a clear “your previous tracking link no longer works because Sendle has closed; here’s how to find your order status” message; a one-time email to customers with outstanding Sendle shipments giving them new tracking references where available and an explanation where they aren’t; a temporary chat or form route specifically tagged for Sendle-related inquiries so your team can batch the responses.

What about international shipping? For international, the aggregator path is more attractive because the carrier set required for global coverage (DHL Express, FedEx, Australia Post International, plus various regional partners) is genuinely complex to build and maintain. Most stores doing meaningful international volume use Starshipit, Shippit, or Easyship for the international layer even if they handle domestic differently.

Does this apply if I’m on Shopify Markets or Shopify Shipping? Shopify Shipping is itself an aggregator layer — you’re relying on Shopify to handle the carrier abstraction. That works well for stores that fit Shopify’s assumptions about shipping (single warehouse, standard service levels, no own-fleet) and pay an acceptable rate. The patterns in this article apply when you need to step outside what Shopify Shipping covers, or when you want carrier-specific rates that Shopify doesn’t pass through.

If you’re mid-migration off Sendle, or you’re thinking about the shipping layer differently after the January event, start a project and we’ll walk through the architecture choices against your specific shipping volume and carrier mix.