The rates work one day and not the next. The products are unchanged, the address is valid, and the carrier-rate app in the admin still shows a green Active. The only thing anyone can point to is that the app updated a few days earlier. If that is your store, the cause is a platform change, not a broken app.
That sequence is not a coincidence, and it is not your store breaking. On 26 June 2026, Shopify posted a breaking change for Admin GraphQL API version 2026-10: a carrier service created through the API is no longer added to the shop’s General shipping profile automatically. It is now registered and left there, with nothing pointing checkout at it, unless it is explicitly attached.
What actually changed in API version 2026-10
Before 2026-10, creating an active carrier service through carrierServiceCreate (or the REST equivalent) did two things: it registered the service, and it added the service to eligible zones in the shop’s General shipping profile. The second part was invisible, which is why most stores never knew it happened. Shopify’s own wording for the new behaviour is blunt: creating a carrier service now “only registers the carrier service,” and the platform “no longer adds that carrier service to the General shipping profile or any of its shipping zones by default.” Without the extra step, “merchants won’t see rates from newly created carrier services at checkout.”
Two details decide whether this is your problem at all.
- It affects created services, not existing ones. A carrier service that is already attached to a profile is not detached by this change. The rates vanish when an app creates the service fresh — on a reinstall or a rebuild of the service — under version 2026-10.
- It is version-gated. Shopify says older supported API versions keep the old automatic-add behaviour until they are sunset. So the date a given store hits this is the date its app moves to 2026-10 or later. That is why it reads as “after an app update” rather than as a platform-wide outage on one day.
Why it looks like an app update, because it usually is
Apps routinely bump the Admin API version they run on, and Shopify requires it over time as older versions are retired. The moment an app that manages a carrier service moves to 2026-10, any carrier service it creates from then on is no longer auto-attached. If the app never added the attach step — because for years it never needed to — the update is the trigger and the app is not necessarily broken. It is doing exactly what the new API contract says it should.
The same shape appears when the service is re-created rather than updated. A reinstall, a re-authorisation, or an app rebuild can replace the old registration with a new one. The new registration starts unattached, and the old, attached one is gone. From the merchant’s seat it is one carrier service that stopped working; in the API it is a different record.
There is a second, unrelated way a carrier service goes quiet, and it is worth ruling out because the symptom is identical: the store’s plan. Carrier services require the Advanced plan or higher, or the Shopify plan with yearly billing or the carrier-service add-on, or a development store. Shopify states that if a store changes plan and no longer meets one of those requirements, “the store’s association with a carrier service is deactivated.”
The five-minute check that tells you which case you have
Do not start by rebuilding anything. Establish which of these you are looking at, because the fix is different for each.
Comparison table — scroll horizontally to see all columns
| What you find | What it means | Where to fix it |
|---|---|---|
| The carrier-calculated rate is missing from the zone in Settings > Shipping and delivery | The 2026-10 attach step was skipped | Re-add the rate to the profile — admin or API |
| The rate is present in the profile, but the app’s callback is failing | Shopify is falling back because the rate endpoint errored or timed out | Fix the callback, then re-test it |
| The service no longer appears in the app at all | The carrier service was deleted or replaced | Re-create it, then attach it |
| The store’s plan changed recently | The association was deactivated by the plan | Upgrade or add the feature, then re-attach |
| Everything looks right but only some zones are empty | The rate was attached to the wrong profile or zone | Move it to the profile that covers those products |
How to fix it
Route one — the merchant adds the rate in the admin. This is the route Shopify recommends first. In Settings > Shipping and delivery, open the shipping profile that covers the affected products, open the relevant zone, and add a rate that uses carrier or app calculation, selecting the carrier service. Shopify’s help describes shipping profiles and zones as the container that decides which products a rule applies to, so the profile choice matters as much as the rate itself.
Route two — attach it programmatically. For anything beyond a single profile, the shipping profile APIs are the honest path: add the carrier-calculated rate to the appropriate profile and zone from the app. Shopify names exactly this as the second option in the changelog. If your app writes to merchant-managed delivery profiles, also check the February 2026 changelog on shipping options in delivery profiles, which requires apps that write merchant-managed profiles to move to the new write API to avoid unexpected behaviour.
Prove it with a real checkout, not a screenshot. Set a shipping address in an affected zone, reach checkout, and confirm the option appears with the expected name and price. A rate that exists in the admin and a rate that appears at checkout are the same thing only after this test.
Put backup rates in place before you touch anything. If a calculated rate fails — a 40x/50x response, a timeout, or an empty array — Shopify shows backup rates only when they exist and no other eligible rate is available. Adding a flat backup rate is what stops a missing carrier rate from becoming a blocked checkout.
What the callback has to do, in code
A carrier service is a public POST endpoint that Shopify calls at checkout with the origin, destination and items, and it must answer with a JSON array of rates in a single response. The price is in subunits, so "total_price": "500" is 5.00 in the store’s currency. Returning an empty array with a 20x status says “no rate for this cart”; returning a 404 tells Shopify to use backup rates. There is no retry: the first response has to work, inside a timeout that tightens as request volume rises (10 seconds under 1,500 requests per minute, down to 3 seconds over 3,000), and identical requests are cached for 15 minutes.
The create call itself is unchanged in shape — only the attach step moved out:
mutation CreateCarrierService($input: DeliveryCarrierServiceCreateInput!) {
carrierServiceCreate(input: $input) {
carrierService { id name callbackUrl active }
userErrors { field message }
}
}{
"input": {
"name": "Regional delivery",
"callbackUrl": "https://rates.example.com/rates",
"supportsServiceDiscovery": true,
"active": true
}
}On API version 2026-10 this returns the service and registers it. It does not place it. The attach is a separate write: the profile update exposes the carrier service as a rate provider — a DeliveryParticipant that carries the carrierService id — inside a method definition for the zone you want it in, or the merchant adds it by hand.
How I verify this in real implementations
I have built exactly this kind of shipping-rate app, so the failure mode is familiar rather than theoretical. For a club and school kit retailer, native shipping settings could not express the rule: an order made up of a single club or school collection ships free as collection from that club or school, while a mixed-cart order pays delivery priced by zone. I built a carrier-rate endpoint called at checkout that resolves each line item to its collections and applies the rule, with a priority rule engine over collections, cart totals, customer tags and destination country, pricing profiles with country-specific rates, and a no-code rule builder, plus product and collection sync.
That app grew into a productised version, where the checkout-critical callback is the part I hardened hardest: a per-shop 192-bit token instead of a spoofable shop header, rate limiting on the endpoint, and a design that fails safe so a bad rule never breaks checkout. The productised line carries about 320 tests. Its deployment is reported only at the original client, and there is no App Store listing — I say that rather than imply scale that does not exist.
I keep a simple rule from that work: a rate endpoint must fail safe, and the moment it stops failing safe, the store can no longer take money. That is why the answer to “the rates disappeared” is never to guess at the app — it is to prove which of the five states above you are in, and fix that one.
“[He] made the perfect app for us and is brilliant to work with.”
— Upwork client, 2026
Common failure modes
- Assuming the app is broken. Under 2026-10 the app can be entirely correct and still leave rates unattached. Fix the attach, not the app.
- Re-adding the rate without checking for an existing one. That produces two options in the same zone; remove the stale method definition instead of stacking.
- Changing the plan first. A plan change can deactivate the association; confirm the plan requirement before you spend a day on the app.
- Testing in the admin only. The admin shows what exists; checkout shows what Shopify will actually offer. Test in checkout.
- Skipping backup rates. A failing callback with no fallback is a checkout that refuses to complete, which is worse than a missing option.
Limitations
- This is an API behaviour change, not a data loss event. Nothing historical is reprocessed; the option simply stops being offered for newly created services that are not attached.
- Version timing differs per app. Older supported versions keep the old behaviour until sunset, so two stores running the same app version can see different results.
- Programmatic attach is not one size fits all. Merchant-managed profiles and app-managed profiles are written differently, and apps that write merchant-managed profiles may need the newer shipping-option API.
- Plan eligibility can override everything above. No attach will help a store that no longer meets the carrier-service plan requirement.
- This covers technical implementation, not legal or tax advice.
When you don’t need this
If your store uses only flat or weight-based rates and no carrier service, this change does not touch you. If a single rate went missing but the app still shows it attached everywhere, you are looking at a failing callback or backup-rate issue rather than the 2026-10 change. And if you have exactly one zone and one rate on a store you can edit yourself, the admin route takes minutes — paying anyone for it would be the wrong call, and I will say so.
I can build this for you
This is the use case Native Shipping Settings Can’t Express Your Rules: Custom Shipping Rates at Checkout.
It starts with a free discussion: describe your task, and I will confirm whether this is the 2026-10 attach step, a failing callback, or a plan change, before anything is changed.
Typical route: re-attaching a missing carrier rate across one store’s profiles is a Focused Fix from USD 450 / EUR 425. Building or hardening the shipping-rule logic itself — collection, cart and destination rules, a safe callback, the attach handled in code — is a Custom Engineering Project from USD 1,500 / EUR 1,400. If it is not yet clear which case you have, a Working Session (USD 195 / EUR 185) pins down the cause on one question before anything is changed.
Describe your task.
