Shopify Stops Auto-Adding Carrier Rates in API 2026-10
Shopify's API 2026-10 no longer auto-adds carrier services to shipping profiles. Learn what breaks and how to fix carrier-calculated rates before checkout fails.
Shopify stops auto-attaching carrier rates, starting with API 2026-10
Shopify confirmed in a developer changelog entry that, starting with GraphQL Admin API version 2026-10, creating a carrier service no longer automatically adds it to the shop's General shipping profile. The entry was published on June 26, 2026, and version 2026-10 became the latest stable Shopify Admin API version on October 1, 2026. If you run a Shopify storefront and pull live rates from DPD, GLS, PostNL, DHL or any other carrier into checkout, this is the kind of quiet platform change that breaks things weeks after you've stopped watching for it.
Two endpoints are affected directly. According to Shopify, this breaking change affects carrier services created using GraphQL Admin API's carrierServiceCreate and REST Admin API's POST /admin/api/{version}/carrier_services.json. If your integration (or your app vendor's integration) calls either of these to register a Shopify carrier service API object, you are in scope.
Why this is a carrier-connectivity problem, not just a Shopify problem
The carrier service object is exactly the mechanism this blog's readers use to surface carrier rate data at checkout. It's the bridge between your carrier API and the Shopify storefront. Break that bridge quietly, and nobody notices until a customer hits an empty shipping step.
Here's the old behavior versus the new one. Shopify states that previously, active API carrier services created through these APIs were automatically added to eligible shipping zones in the shop's General shipping profile. That default is gone. In API version 2026-10 and later, creating a carrier service only registers the carrier service, and Shopify no longer adds that carrier service to the General shipping profile or any of its shipping zones by default.
The API call still returns a success response. The carrier service object exists in Shopify's system. But without these additional steps, merchants won't see rates from newly created carrier services at checkout. A Shopify community member summed up the failure mode bluntly, posting this warning because the issue "fails silently and Q4 is close." No error log, no failed webhook, no alert. Just an empty rate list at the one moment a customer is ready to pay.
Who gets hit, and the timeline
The scope is narrower than "every Shopify store with carrier rates," but it still catches a lot of in-house integrations. Per Shopify's own changelog and the community thread tracking it:
| Date | Event |
|---|---|
| June 26, 2026 | Shopify publishes the changelog entry announcing the change |
| October 1, 2026 | API version 2026-10 becomes the latest stable version; the new behavior takes effect for carrier services created on this version |
| Ongoing | Older supported API versions will continue to use the existing automatic-add behavior for carrier services in the General shipping profile until those versions are sunset |
Who's exposed? Stores that install, reinstall or migrate an app that shows live carrier rates, if the app uses the new API version are affected. A working integration built on an older API version doesn't break by itself. It breaks the moment someone reinstalls the app, rebuilds the connection, or migrates it to 2026-10, which is exactly what happens during a carrier switch, a rate renegotiation, or a routine app update.
What breaks at checkout, concretely
Walk through what used to happen automatically. An app (or your own dev team's code) called carrierServiceCreate, Shopify registered it, and the rate appeared in the shop's shipping zones without anyone touching the admin panel. That chain is now broken in the middle. Shopify's own guidance is direct about the fix: after creating a carrier service, you must ensure that its rates are added to a shipping profile, either by directing merchants to manually add the carrier-calculated rate to the appropriate shipping profile in the Shopify admin, or by programmatically adding the carrier-calculated rate to the appropriate shipping profile using the shipping profile APIs.
This hits both categories of reader equally. A no-code merchant app that creates carrier services on your behalf is exposed if its vendor hasn't shipped a fix for 2026-10. And if your IT team wrote the carrierServiceCreate call directly against a carrier's rating API, you own this gap personally. There's no vendor to escalate to.
The fix, and the deadline that already passed
Technically October 1, 2026 is behind us, but the exposure window is ongoing, since older API versions still work until Shopify sunsets them. Treat this as live, not historical:
- Inventory every app and in-house script that creates a carrier service, and confirm which API version each one calls.
- If any of them are on 2026-10 or are being migrated to it, add the carrier-calculated rate to the relevant shipping profiles explicitly, either through the admin UI or the shipping profile API, before go-live.
- Test every shipping zone you serve, not just the default one. The community guidance specifically recommends you place a test order to each shipping zone you serve, including products in separate profiles.
- Screenshot your current shipping setup before any app reinstall or migration so you have a known-good baseline to compare against afterward.
Don't do this in isolation either. Shopify is running a parallel migration called market-driven shipping, which replaces shipping profiles and zones with shipping options configured per market. Rollout for that system began opting in on October 1, 2026, with full migration by July 1, 2027. If you're rebuilding your carrier service attachment logic now, design it against where shipping configuration is heading, not just where it sits today.
The bigger pattern: carrier plumbing keeps moving under shippers' feet
This is the same category of risk this blog tracks every time DHL, FedEx, UPS or DPD touch their API surface. A platform changes a default behavior, and whoever owns the integration absorbs the operational risk, whether that's a two-person IT team at a mid-sized wholesaler or a 50-person carrier connectivity function at a major retailer.
Multi-carrier shipping platforms and TMS systems that maintain their own Shopify connectors, such as Sendcloud, ShipStation, EasyPost, Shippo or Cargoson, absorb changes like this centrally, which means individual shippers aren't personally responsible for tracking every quarterly Shopify release note. That's a genuine trade-off worth weighing against the cost and flexibility of running your own integration.
If you maintain your own connection, the lesson here isn't really about Shopify specifically. It's that "installed and working" is not the same guarantee as "will still work after the next reinstall." Audit your carrier service calls before your next app update, not after a customer reports a blank checkout page.