App controlled shipping profiles do not work if there are flat rates setup in the general shipping profile
Reproduction steps
Add any flat rate directly to the shopify general shipping profile.
If there are any rates setup via Carrier Service in an app controlled shipping profile (with coversAllItems: true), the carrier service rates are ignored, Shopify does not even request rates from the app, only the flat rates are shown.
Expected bahaviour
Expected behaviour is that both flat rate AND the carrier service rate is surfaced.
I work with Nick, and this is what I noticed. I was attempting to take the suggested upgrade path for market based shipping. With this bug in place it makes using app delivery profiles as a migration strategy infeasible.
I also noticed there is no webhook when a merchant upgrades to markets, so managing both app profiles and legacy profiles automatically isn’t possible. It will require merchant intervention. Unless, of course, this bug is fixed.
Worth checking this against the 2026-10 change where carrier services stopped auto-attaching to the General profile, if you’re still on an older API version that auto-adds them, the General profile may be claiming rate priority before your app profile gets queried. Either way, with Nick and Richard reproducing the same thing independently this looks like a real platform bug rather than a config issue, worth filing with Partner Support since there’s no staff response yet.
Good to rule out, that makes it a solid platform bug rather than a version quirk. With three of you reproducing it independently I’d push the Partner Support ticket if it’s not already filed, that’s usually what gets eyes on it faster than the forum.
oh really? in my experience, the forums yields a much faster turnaround time, last time i raised both, someone had already started looking at the issue after a few days and my shopify partner ticket took 2 weeks before they decided it was a bug and forwarded it to the right team!
Fair, doing both in parallel is probably the better move then, forum for visibility and the ticket for a paper trail in case you need it escalated later.
@Min_Liu FYI, from the records I saw on the forum Mubashir Hassan is using AI to create content and self promote themselves via excessive presence and sounding like an expert to impress people. I would ignore their message
Hey folks - thanks for the examples and context. I’ve confirmed the behaviour in Min’s example: checkout uses the general-profile flat rate, and the app rate appears after that rate is removed.
We’re currently looking into this and I’ll update this thread as soon as I have more to share.
Hey @Min_Liu and @Richard_Blair - I’ve confirmed how coversAllItems: true behaves before and after migration to market-driven shipping:
Before migration, the app-controlled profile acts as a fallback. If the item’s own shipping profile has an applicable rate at the same location, that rate takes precedence. That’s why the general-profile flat rate wins in Min’s example.
After migration, both the merchant’s market rates and the app-controlled covers-all rates are offered.
The behaviour you’re seeing before migration is intended, but the documentation doesn’t make that distinction clear. We’re reviewing it to clarify this.
Min, the market-driven shipping opt-in banner should also now be visible on your existing dev store.
Understood. Unfortunately for us this means simply switching to app profiles as a migration strategy won’t work. Existing merchants not yet on Markets would expect their Parcelify shipping rates continue to work, so we can’t just move them into an app profile.
Wes, I am curious, though - is there a webhook or notification we can subscribe to so we know when a merchant upgrades?
As per what @Richard_Blair said, the first migration pathway isn’t going to be valid anymore as it differs in behaviour for stores who have not migrated yet. The documentation should be updated to reflect this too.
thanks for flagging this.