Shopify has deprecated merchant-owned delivery profile APIs for shops that adopt its newer shipping model, replacing that logic with server-side cart and checkout validation Functions. If your store has custom shipping rules — restricted destinations, weight-based exceptions, product-specific carrier rules — built against the old delivery profile API, that integration needs to move before the deprecation reaches your shop, not after something breaks at checkout.
Why the API Model Changed
The old delivery profile API let merchants and apps manage shipping logic as data attached to profiles — a reasonable model until you needed logic more complex than “these products ship from this location under these rates.” Validation Functions move that logic to server-side code that runs during cart and checkout, which means conditions that used to require profile gymnastics — “block this product combination from shipping to this region” or “require a minimum order value for this carrier” — are now expressed as actual validation logic rather than approximated through profile configuration.
What to Inventory Before Migrating
| Item | Why It’s Needed |
|---|---|
| Every custom shipping rule currently live, in plain language | This is the actual specification for what the Function needs to replicate — profile configuration alone won’t capture intent that was worked around rather than directly configured |
| Any third-party app currently reading or writing delivery profiles | These apps may not be updated for the new model yet, and a broken integration here fails silently at checkout, not with a visible error |
| Edge cases handled through manual overrides or support workarounds | These rarely exist in written documentation and are the most commonly lost requirement in this kind of migration |
| Current checkout error messaging | Confirms the new Function’s rejection messaging matches or improves on what customers currently see, rather than surfacing a generic error |
Migration Steps
- Document current rules as test cases — for every shipping restriction or condition, write the input (cart contents, destination, order value) and expected outcome (allowed, blocked, modified rate) before writing any Function code.
- Build the validation Function against that test suite, not against a general understanding of “what shipping rules we probably have.”
- Run the Function in a non-production environment against real historical order data — pull a sample of actual past orders and confirm the new Function produces the same allow/block decisions the old profile-based system did, before assuming parity.
- Check third-party app compatibility explicitly. An app that still expects to read or write the deprecated profile fields needs its own update or replacement — don’t assume app vendors have already migrated on your timeline.
- Roll out behind a controlled test — a small percentage of checkout sessions, or a single market — before full cutover, and monitor checkout completion rate specifically during that window, since a shipping validation bug shows up as abandoned checkouts, not as an obvious error report.
- Keep the old configuration documented and accessible for a defined rollback window even after cutover, since Function-based validation bugs can be subtler than the profile-based rules they replace and may not surface on day one.
The Risk That’s Easy to Miss
Delivery profile rules were data — visible, auditable, and changeable without a deploy. Validation Functions are code, which means a shipping rule change now goes through whatever code review and deployment process your team uses for Functions generally. If that process is slower than “someone in ops updates a profile setting,” build in a lightweight way for non-developers to request and verify shipping rule changes, or this migration quietly makes shipping configuration harder to maintain even though it’s more powerful.
