The Shopify Checkout That Showed No Shipping Rates and No Error
The checkout had no shipping options, and the absence was the symptom, and the symptom was the silent, and the silent was the no error, and the no error was the app's install, and the install was the success, and the success was the carrier service, and the carrier service was the registered, and the registered was the not the profile, and the not profile was the missing step, and the missing step was the platform's change, and the change was the yesterday, and the yesterday was the 2026-10 release.
This is the anatomy of the silent rate failure that landed with Shopify's 2026-10 API version, and of the specific property that makes it hard to find: the app installs cleanly, the carrier service exists, and checkout simply has nothing to show, so there is no exception, no error page, and no log line to search for.
If you run a Shopify store or build on its APIs, this is worth ten minutes today, because the change is live, the window before peak is short, and the failure mode is invisible until a customer reaches the last step.
What actually changed
Shopify announced on 26 June 2026 that from GraphQL Admin API version 2026-10, creating a carrier service no longer adds it to the shop's General shipping profile. The version became stable on 1 October 2026, which is yesterday.
The affected calls are carrierServiceCreate over GraphQL and POST /admin/api/{version}/carrier_services.json over REST. Before this version, an active carrier service created through those calls was automatically added to the eligible shipping zones in the General shipping profile, so the rates appeared at checkout with no further work. From 2026-10 onward, the same call only registers the carrier service. Shopify's own changelog is direct about the consequence: without the extra configuration step, merchants will not see rates from newly created carrier services at checkout.
Older supported API versions keep the automatic behaviour until they are sunset, which is why nothing broke for existing installs. The exposure is narrow and specific: carrier services created on 2026-10 or later.
Why it is silent
The failure has no error because nothing failed. The app called the API, the API returned a created carrier service, and the app's job was done. The missing piece is a second operation that used to be implicit and is now explicit, and an implicit step that disappears does not raise, it simply stops happening.
The result at checkout is an empty rate list. The customer sees no shipping options and cannot complete the order, and the merchant sees a checkout that looks fine in every admin screen, because the carrier service is there and active. The only place the gap is visible is the shipping profile, which is not where anybody looks when the report is that checkout is broken.
This is the same shape as the silent default that hid the missing config, where a fallback turned a configuration error into a service that ran with the wrong behaviour, and the absence of an error was the reason it lasted a week. A missing implicit step and a silent default are the same failure: the system does the reasonable thing and never tells you it guessed.
Who is exposed
The risk is concentrated in three situations, and all three are common in the weeks before peak.
New app installs. A merchant installs a shipping rate app today, the app creates a carrier service on 2026-10, and no rates appear. The merchant blames the app, the vendor blames the platform, and the checkout stays broken until somebody opens the shipping profile.
Reinstalls and migrations. An app that is uninstalled and reinstalled creates a new carrier service, and the new one is not the old one, so the profile assignment does not carry over.
App-side version bumps. An app that upgrades its pinned API version to 2026-10 inherits the new behaviour on the next carrier service creation, which may be during a merchant's onboarding flow rather than a deploy anybody is watching.
Existing stores with an already-assigned carrier service keep working, which is why this will not show up in a general health check and will show up in support tickets instead.
What to check today
List every app that creates a carrier service. Shipping rate apps, multi-carrier platforms and 3PL connectors are the usual three. Ask each vendor which API version they are on and whether they handle the profile assignment themselves on 2026-10.
Open Settings, then Shipping and delivery, then the relevant shipping profile. Confirm the carrier-calculated rate is actually listed there. If the app appears installed but its rate is absent from the profile, that is the bug, and the fix is to add it using the Add rate option and choosing the carrier or app-calculated source.
Place a test order per shipping zone. Not once. The failure is per zone and per profile, and a single test order proves one path. Weekly test orders through peak is the cheap insurance, because the only place the failure is observable is the last step of checkout.
Check the rest of the 1 October cluster while you are in there. The same date started the script tag write shutdown, with scriptTagCreate and scriptTagUpdate returning errors on every API version and storefront injection ending on 1 March 2027. It also opened the market-driven shipping opt-in and closed the Polaris web-components migration window for checkout extensions. None of those are the shipping bug, and all of them are the same kind of quiet deadline.
The fixes
For app developers: assign the profile explicitly. Shopify's recommended path is to direct the merchant to add the rate manually, and the programmatic path is to add the carrier-calculated rate to the shipping profile through the shipping profile APIs. Do one or the other, and do not rely on the registration call.
For merchants: treat the profile as the source of truth. The carrier service existing is not the same as the rate being available. The profile is where availability lives.
Alert on the zero-rate checkout. A cart that reaches the shipping step and receives no rates is the detectable signal, and the signal is the alert, and the alert is the difference between finding this in an hour and finding it in a support thread.
The rule
From Shopify API 2026-10, creating a carrier service registers it and nothing more, so the rate must be added to a shipping profile explicitly or checkout silently shows no options. Audit every app that creates a carrier service, verify the rate exists in the profile, and test-order each shipping zone weekly through peak.
The checkout shows no shipping rates and nothing anywhere reports an error, because the app did its job and the platform stopped doing the second job it used to do for free, which is the shortest definition of this change I know: an implicit step became an explicit one, and implicit steps do not fail loudly when they disappear, so the only symptom is a customer who cannot finish buying something, six weeks before the busiest week of the year.
