Scalable Shopify Plus Architecture: Patterns for 2026

The decision this guide helps you make: you have a Plus store with a recurring problem (promotions that break, checkout changes that hurt, integrations that duplicate or drop orders) and someone has proposed a rebuild. Can you fix it without rebuilding the storefront, and if not, what is the smallest move that works?

The constraints that decide the answer: what the platform supports today, which plan you’re on, who owns each kind of data, and how much change your team can safely ship.

Shopify platform status, checked 2026-10-18 (don’t skip):

• Shopify Scripts are gone. Editing and publishing new Scripts stopped on April 15, 2026, and all Scripts stopped executing on June 30, 2026 (Shopify developer changelog)¹. Discount, shipping, or payment logic that lived in Scripts must now live in Shopify Functions or an app. Stores on any plan can use public apps that contain Functions; only Plus stores can use custom apps that contain Function APIs (Shopify Functions)².
• checkout.liquid is unsupported for the Information, Shipping, and Payment steps, and was sunset for the Thank you and Order status pages on August 28, 2025. Script tags on those pages were sunset for Plus stores on the same date and are sunset for non-Plus stores on August 26, 2026. Checkout customization goes through checkout extensions (Shopify: checkout.liquid)³.
• The REST Admin API is legacy as of October 1, 2024, and new public apps must use the GraphQL Admin API from April 1, 2025 (Shopify: REST Admin API)⁴. Plan new integrations on GraphQL.

What scalable Shopify Plus architecture actually means

Scale on Shopify Plus is rarely about raw traffic. It’s about operational load: how fast you can change promotions without breakage, how often integrations cause incidents, and how confidently you can expand to new markets without cloning logic.

The workable boundary is simple: Shopify runs the commerce primitives; your stack runs experience and orchestration. The hard part is governance, deciding where each rule lives so you don’t rebuild a bespoke commerce platform by accident.

This guide gives you a decision matrix, a checkout pattern map, a worked integration scenario with failure tests, a readiness checklist, and a migration sequence with rollback. The rule underneath them is consistent: make the smallest move that resolves the constraint, then stop.

The constraint model: why Plus projects fail at scale

Constraint: release velocity vs merchandising autonomy

If merchandising can change promotions daily, your architecture must support frequent rule changes with a predictable blast radius. When promo logic is embedded in storefront code, every campaign becomes a deployment, and every deployment becomes a potential incident.

A scalable system turns “promo change” into a governed change type: validated inputs, predictable execution, and a kill switch. If you can’t roll back a promo in minutes, your team will eventually “solve” the problem with one-off exceptions, and that’s how complexity becomes permanent.

Constraint: consistency vs experimentation

Global brands want region-specific experiences and fast experimentation. The trap is solving this by duplicating business rules across multiple codebases. Consistency failures don’t show up as compilation errors; they show up as revenue leakage, support escalations, and hard-to-debug edge cases.

Treat business rules as products: define owners, define contracts, and define what “done” means (tests, monitoring, rollback). Scaling is less about clever patterns and more about refusing to let exceptions become architecture.

Constraint: integration load and incident rate

As the integration surface grows, the dominant risk becomes the incident taxonomy: duplicates, partial failures, retries that amplify load, and silent drift between systems. If your integration is a set of implicit assumptions, you will eventually run on folklore instead of contracts.

GraphQL is a good query shape, but it’s not a substitute for domain boundaries. When teams use it to paper over unclear ownership (who owns the truth, who can write, what “done” means), they create ad hoc coupling, the opposite of scale.

Shopify-first baseline: the architecture that stays upgradeable

A Shopify-first baseline is a governance decision more than a tech choice. It says: keep commerce behavior in official extension points, keep writes contract-first, and make replaceability a requirement.

Rule set: what goes where (and why)

1. Keep business rule execution in Shopify Functions when the rule is part of commerce truth (discounts, delivery and payment customizations, cart and checkout validation). This keeps behavior close to the commerce primitive. Check the plan constraint first: custom apps with Functions need Plus.
2. Keep checkout UI changes inside checkout extensions, and treat UI as presentation, not the source of truth. A checkout UI should request and display state, not invent it.
3. Keep integration writes explicit and idempotent. If an integration can be retried, it will be retried; design for it from day one.
4. Keep one owner per domain, and version everything that crosses domains: payload schemas, event shapes, and failure behavior (what happens on timeout, partial failure, or downstream outage).

Why this baseline is opinionated (and worth it)

A lot of “scale architecture” content starts with headless and ends with a bespoke platform. That path can work, but it fails in a predictable way: the team accidentally creates a second commerce brain outside Shopify, then spends quarters reconciling drift.

The Shopify-first baseline is a constraint: it forces you to justify every external service with a measurable gain, and to design rollback before you ship. That’s the difference between composable and chaotic.

The decision matrix: do less, native, headless, or middleware

Use the matrix when someone asks “Should we go headless?” or “Do we need middleware?” and you want the smallest move that solves the current constraint. If you want a deeper comparison of storefront architecture, pair this with Shopify Hydrogen vs Liquid: When to Go Headless.

Shopify Plus scaling decision matrix

Trigger	Recommended	Shopify Primitive	Avoid	Evidence to collect first
A rare incident with a clear cause	Do less: fix that failure; no architectural change	None	Turning one incident into a replatform	Incident log: frequency, cost, owner
Frequent promo changes cause regressions	Move rule execution to Shopify Functions	Shopify Functions	Discount logic split across multiple storefronts	Which rules break, how often, who changes them
Checkout changes break upgrades	Use checkout extensions; keep logic out of the UI	Checkout extensions	Hidden checkout hacks and brittle DOM targeting	List of current checkout customizations
Multi-region expansion multiplies exceptions	Use Shopify-native regionalization before duplicating logic	Shopify Markets	Region forks with duplicated rule sets	Rules that differ by region, and why
Storefront performance constraints	Add edge caching and tighten read paths before rewrites	Storefront API	Client-only rendering that hides content from crawlers	Field performance data for the slow templates
Complex B2B requirements collide with ops	Keep commerce truth centralized; expand workflows carefully	Shopify Admin	Spreadsheet-driven omnichannel processes	Authority map for customer and pricing data
Integration incidents from retries/duplicates	Introduce a contract-first, idempotent write path	Admin API + webhooks	Point-to-point “best-of-breed” sprawl	Duplicate and missing records per system
Need custom UX without touching checkout	Go headless for the storefront only; keep Shopify checkout	Storefront API	Rebuilding the order lifecycle outside Shopify	Which experiences themes can’t deliver
Replatform pressure (“Shopify can’t do X”)	Validate the smallest native move; delete unnecessary middleware	Shopify Plus	Premature “rewrite to scale” mandates	The specific X, checked against current Shopify docs

How to read it: if your trigger is about business rules, fix the execution layer first. If it’s about experience, isolate it to storefront surfaces. If it’s about reliability, fix the write path and observability before you add more systems.

Comparing the options

When more than one row applies, compare the candidate moves on four criteria and write the answers down:

• Complexity cost: how many new systems, deploy paths, and owners does it add?
• Upgrade path: does it stay on supported Shopify extension points, or does it depend on something Shopify can retire (as it did with Scripts and checkout.liquid)?
• Operational load: who is on call for it, and what breaks at night?
• Reversibility: can you turn it off in minutes without data loss?

Prefer the option that is reversible and stays on supported extension points, even if it’s less ambitious. Choose a larger move only when the smaller one demonstrably fails to resolve the trigger.

Checkout and promotions: where Plus programs get fragile

A slow homepage is rarely what sinks a Plus program. An untestable promo system and a checkout that breaks under constant change do far more damage.

Treat checkout UI and rule execution as separate problems. UI changes should be composable and reversible. Rule execution should be deterministic, observable, and governed.

Checkout customization patterns (extensible vs fragile)

customizationGoal	recommendedPattern	riskLevel	whyItScales
Add contextual messaging (trust, shipping, returns)	UI-only extension with no new write paths	Low	Changes are reversible and don’t create data truth conflicts
Conditional payment/shipping availability	Move constraints into governed rule execution (Functions)	Medium	Keeps business rules close to the commerce primitive and reduces divergence
Block/validate problematic carts (policy constraints)	Deterministic validation with explicit failure messaging	Medium	Failure behavior becomes predictable; avoids “mystery declines”
Complex discount stacking rules	Centralize discount logic; avoid storefront duplication	Medium	Reduces promo sprawl and makes testing tractable
Post-purchase upsell flows	Isolate to workflow-driven orchestration	Medium	Keeps commerce truth separate from experience experiments
“Custom everything” checkout experience	Avoid unless there’s a quantified constraint	High	Increases upgrade risk and creates a long-lived maintenance surface

A practical stance: if your “checkout customization” requires fragile coupling, you’re not customizing checkout; you’re taking on a platform maintenance obligation. Choose customization that stays upgradeable, not customization that wins a demo.

Rollout design (feature flags), kill switches, and test strategy are the mechanics that make this safe. They only work when your architecture boundaries are already sane.

Multi-region and B2B reality: designing for operations, not demos

Shopify Markets is not a “multi-currency toggle.” It’s Shopify’s native model for selling internationally (Shopify: about Shopify Markets, accessed 2026-10-18)⁵, and international selling is a complexity multiplier: regional pricing expectations, catalog differences, tax behavior, and fulfillment rules collide with operational workflows.

The common failure mode is duplicated business logic outside Shopify. It starts as “just a regional override,” then becomes a second commerce brain that the team must reconcile every quarter.

Use the Admin API as an operational boundary: decide which system is authoritative for customer segments, pricing inputs, and fulfillment signals. Then enforce it with explicit contracts and change workflows, not chat messages.

A useful mental model is the operational contract: what data is authoritative where, who is allowed to change it, and how changes propagate. If you can’t answer those three questions per domain, your architecture will drift no matter what stack you pick.

Integrations that don’t melt: a worked scenario with failure tests

Admin API integrations fail in predictable ways: duplicate writes, partial failures, and retries that amplify load. You don’t fix these with “more monitoring.” You fix them by making the write path explicit and idempotent, then testing the failures on purpose.

Here is one scenario end to end: new orders flow from Shopify to an ERP, and the ERP’s order reference and stock adjustments flow back. The platform facts below were checked against Shopify’s documentation on 2026-10-18.

What Shopify guarantees, and what it doesn’t

• Webhooks can arrive more than once and out of order. Shopify tells you to ignore duplicate deliveries using X-Shopify-Webhook-Id, says it doesn’t guarantee ordering within a topic, and suggests ordering by X-Shopify-Triggered-At or the payload’s updated_at (Shopify: webhook best practices, accessed 2026-10-18)⁶.
• Delivery isn’t guaranteed. The same page says your app shouldn’t rely on webhooks alone and recommends periodic reconciliation jobs that fetch recently updated objects.
• Respond quickly, or it counts as a failure. Your endpoint must respond within five seconds; Shopify retries failed deliveries up to eight times over four hours and removes the subscription if failures persist (Shopify: troubleshooting webhooks, accessed 2026-10-18)⁷.
• Verify every delivery. Each webhook carries a base64 HMAC-SHA256 signature of the raw body, made with your app’s client secret, in X-Shopify-Hmac-SHA256 (Shopify: deliver webhooks through HTTPS, accessed 2026-10-18)⁸.
• Only some Admin mutations support idempotency keys. The @idempotent directive covers a listed set of inventory, location, and refund mutations, and Shopify made it mandatory for them in API version 2026-04. Keys are tracked for one day; for background jobs Shopify suggests deriving the key deterministically (a UUID v5 from stable inputs) so a retry reuses it (Shopify: implementing idempotency; changelog, both accessed 2026-10-18)⁹. Everything else needs your own idempotency.
• Throttling is cost-based on GraphQL. A throttled GraphQL Admin request returns a THROTTLED error, and responses report query cost in extensions.cost; Shopify recommends backing off for one second when you hit the limit (Shopify: API rate limits, accessed 2026-10-18)¹⁰.

The contract (illustrative)

Versioned payload, a deterministic idempotency key, and declared failure behavior. Adapt the field names to your ERP:

{
	"contract": "order_export.v1",
	"source": "shopify webhook orders/create",
	"idempotencyKey": "order:{shopifyOrderId}:export:v1",
	"dedupe": "X-Shopify-Webhook-Id (best effort) + ERP unique constraint on external_id (guarantee)",
	"writePath": "single writer: one queue consumer per ERP",
	"retryPolicy": {
		"maxAttempts": 5,
		"backoff": "exponential with jitter",
		"retryOn": ["HTTP 429", "HTTP 5xx", "timeout", "GraphQL THROTTLED"]
	},
	"failureBehavior": { "deadLetterQueue": true, "alertOn": "any message in the dead-letter queue" },
	"writeBack": {
		"erpOrderRef": "metafieldsSet on the order (setting the same value twice is harmless)",
		"stockAdjustments": "inventoryAdjustQuantities with @idempotent(key: uuidv5(erpMovementId))"
	},
	"reconciliation": "hourly: orders with updated_at since last run and no erp_ref metafield"
}

The receiving end (a Cloudflare Worker)

The webhook endpoint does three things fast: verify, dedupe, enqueue. Everything slow happens in the queue consumer, so the five-second limit is never at risk. This handler was type-checked against the Workers types and tested locally on 2026-10-18 for a valid delivery, a replay, a bad signature, and a malformed signature (Cloudflare Workers documentation, accessed 2026-10-18)¹¹.

// Cloudflare Worker: receive Shopify orders/create webhooks, verify, dedupe, enqueue.
// Bindings (wrangler config): KV namespace DEDUPE, Queue producer ORDERS, secret SHOPIFY_CLIENT_SECRET.
export interface Env {
	DEDUPE: KVNamespace
	ORDERS: Queue<OrderMessage>
	SHOPIFY_CLIENT_SECRET: string
}

export interface OrderMessage {
	webhookId: string
	triggeredAt: string | null
	order: { id: number; updated_at: string }
}

export default {
	async fetch(req: Request, env: Env): Promise<Response> {
		const body = await req.text() // verify the raw body, before any parsing
		const signature = req.headers.get('X-Shopify-Hmac-SHA256') ?? ''
		if (!(await isValidHmac(body, signature, env.SHOPIFY_CLIENT_SECRET))) {
			return new Response('invalid signature', { status: 401 })
		}
		const webhookId = req.headers.get('X-Shopify-Webhook-Id')
		if (!webhookId) return new Response('missing webhook id', { status: 400 })

		// Best-effort dedupe: KV is eventually consistent, so the ERP-side unique key stays the real guarantee.
		if (await env.DEDUPE.get(webhookId)) return new Response('duplicate', { status: 200 })

		await env.ORDERS.send({
			webhookId,
			triggeredAt: req.headers.get('X-Shopify-Triggered-At'),
			order: JSON.parse(body)
		})
		await env.DEDUPE.put(webhookId, '1', { expirationTtl: 7 * 24 * 60 * 60 })
		return new Response('queued', { status: 200 }) // answer fast; the queue consumer does the slow work
	}
}

async function isValidHmac(body: string, signatureB64: string, secret: string): Promise<boolean> {
	let signature: Uint8Array
	try {
		signature = Uint8Array.from(atob(signatureB64), (c) => c.charCodeAt(0))
	} catch {
		return false
	}
	const key = await crypto.subtle.importKey(
		'raw',
		new TextEncoder().encode(secret),
		{ name: 'HMAC', hash: 'SHA-256' },
		false,
		['verify']
	)
	return crypto.subtle.verify('HMAC', key, signature, new TextEncoder().encode(body))
}

For the stock adjustments that flow back, use the directive on a mutation that supports it:

mutation AdjustStock($input: InventoryAdjustQuantitiesInput!, $idempotencyKey: String!) {
	inventoryAdjustQuantities(input: $input) @idempotent(key: $idempotencyKey) {
		inventoryAdjustmentGroup {
			id
		}
		userErrors {
			field
			message
			code
		}
	}
}

Failure tests (run them in a development store before go-live)

Test	How	Pass criterion
Duplicate delivery	Send the same signed payload twice with the same X-Shopify-Webhook-Id	Exactly one ERP order; second response says duplicate
Duplicate that slips past the dedupe store	Clear the dedupe key and replay	Still one ERP order (the ERP unique constraint holds)
Slow ERP	Make the ERP time out on the first attempt	Retry succeeds; one ERP order; webhook answered quickly
Endpoint outage	Return errors from your endpoint for a while, then recover	Shopify’s retries are deduplicated; reconciliation fills any gap
Poison message	Send an order the ERP rejects	Message lands in the dead-letter queue; alert fires
Stock adjustment retry	Send the same inventoryAdjustQuantities request twice with the same key	One adjustment applied (verify the quantity, don’t assume)

The last test matters because developers have reported on Shopify’s community forum that reused keys did not always prevent duplicate adjustments on 2026-04 (community thread, accessed 2026-10-18). We haven’t verified those reports, so test it yourself and keep your own movement ID as a second check.

Overall pass: for the test window, the count of ERP orders equals the count of Shopify orders, no external_id appears twice, every Shopify order has its ERP reference, and the dead-letter queue is empty after you replay it.

Shopify Plus scalability readiness checklist (architecture + ops)

area	check	failureMode	artifact to produce
Performance	Define a read-path budget (cache tiers + invalidation rules)	“Fast sometimes” under load, stale data incidents	Edge caching plan
Promotions	Centralize rule ownership and release workflow	Promo rule sprawl and regressions	Promo change runbook
Checkout	Separate UI changes from rule execution	Checkout fragility during campaigns	Kill-switch pattern
Integrations	Version payload contracts and validate inputs	Integration drift and silent schema breaks	Contract (as above)
Writes	Make every write idempotent	Duplicate orders or fulfillment actions	Idempotency key scheme
Webhooks	Verify, dedupe, enqueue, answer fast	Retry storms, removed subscriptions	Webhook handler + tests
Retries	Use queues and dead-lettering for failure	Retry storms and cascading incidents	Retry taxonomy
Reconciliation	Periodically fetch recently updated records	Silent gaps when a webhook never arrives	Reconciliation job
Observability	Correlate by request and business IDs	“We can’t reproduce it” incidents	Trace and log schema
Release process	Feature flags and progressive rollout defaults	Big-bang releases under uncertainty	Rollout checklist
Ownership	One owner per domain boundary	Everyone owns it → no one owns it	Responsibility map
Data truth	Declare the system of record per entity	Conflicting customer or pricing data	Authority map
Compliance	Document data access and retention	Accidental over-collection	Data boundary policy
Change control	Tie post-incident actions to contracts	Repeat incidents with new symptoms	Incident taxonomy

The checklist is ops-heavy on purpose: a Plus scaling assessment that only checks storefront performance misses the integration drift, rollback safety, and contract versioning where incidents come from.

Headless on Plus: a migration sequence that avoids the rewrite trap

Shopify Hydrogen is Shopify’s framework for headless storefronts (Shopify: Hydrogen, accessed 2026-10-18)¹², and it can be a good choice when storefront experience becomes the bottleneck. But headless is also where teams accidentally rebuild commerce behavior in the wrong place.

Be precise about the Storefront API: it isn’t read-only. It handles buyer-facing reads and writes such as the cart, with token-based access for customer data (Shopify: Storefront API, accessed 2026-10-18)¹³. Keep it to the buyer’s session: browsing, cart, and the handoff to Shopify checkout. Keep operational writes (orders, inventory, fulfillment) on the Admin API behind the governed write path above. The “rewrite trap” is what happens when order lifecycle and promotion logic migrate into custom services without that boundary.

For the fundamentals of headless patterns, start with The Ultimate Guide to Headless Shopify Development.

Migration sequence: Liquid to headless on Shopify Plus

phase	goal	keepStable	changeNow	successSignal
Baseline	Measure current failure modes	Checkout + order lifecycle	Observability + budgets	Incidents have a clear taxonomy
Contracts	Stabilize integration boundaries	Write path ownership	Versioned contracts	Duplicate and missing records trend down
Read path	Improve performance without rewrites	Commerce truth	Caching + rendering strategy	Predictable read latency at the high percentiles
Storefront slice	Migrate one experience surface	Checkout flow	Headless for a subset of pages	Add-to-cart and checkout-start rates hold versus the unmigrated pages
Catalog UX	Improve discoverability + navigation	Pricing rules	Headless components	Merchandising changes stay safe
Regionalization	Expand regions without forks	Source of truth	Region-aware experience	No duplicated rule sets
Full cutover (if justified)	Make headless the default	Commerce primitives	Routing + rollout plan	Rollback tested and boring

Cutover and rollback, step by step

1. Put a router in front of both storefronts. An edge proxy decides, per path, whether a request goes to the Liquid theme or the headless app. Checkout stays on Shopify in every phase.
2. Keep the Liquid theme published for every path you migrate, until the full cutover is done and has run cleanly for a while. It is your rollback.
3. Move one path group at a time (for example, collection pages), behind a flag the router reads.
4. Check parity before each step: URLs and redirects, canonical tags, structured data, analytics events (view_item, add_to_cart), Markets currency and language, and the cart handoff to checkout.
5. Measure the slice honestly. If traffic allows, split visitors randomly between the old and new versions of the same pages; otherwise compare against the unmigrated pages and label the result directional.
6. Rollback is flipping the flag back to the theme. Rehearse it before the first cutover, and time it. If you can’t revert traffic safely, you’re not migrating; you’re gambling.

When you’re ready to go beyond headless into workflow automation, treat it as an operations program, not a novelty. The follow-on guide is Headless Shopify + AI Agents: The 2026 Playbook for Autonomous Merchandising, Support, and Ops.

Reference architecture diagram (Shopify-first, headless-optional)

The diagram is intentionally Shopify-centric. It separates the buyer’s read-and-cart path from the operational write path, because that’s where “scale” gets decided in production.

In words: the storefront (theme or headless) reads catalog data and manages the cart through the Storefront API, and hands off to Shopify checkout. Shopify core is the system of record. Changes leave through webhooks into a queue, a worker writes to the ERP idempotently, and anything that flows back goes through the Admin API.

The operative rule: optimize reads aggressively, and govern writes ruthlessly. If you can’t explain where a write originates and how it’s retried, you don’t have an architecture; you have a collection of scripts.

FAQs: Shopify Plus architecture questions people actually ask

Do I need headless on Shopify Plus?

Usually not as a first move. Use the decision matrix first; promotion change velocity and integration incidents are cheaper to fix than a storefront. Evaluate headless as a targeted move for experiences your theme can’t deliver. For the deeper comparison, read Shopify Hydrogen vs Liquid: When to Go Headless.

What’s the safest way to customize checkout?

Use checkout extensions and separate UI from rule execution. checkout.liquid is no longer an option for the checkout steps, and Scripts no longer run, so anything still depending on either needs a migration plan, not a workaround.

How do we scale promotions without turning every campaign into a deployment?

Treat promotion logic like a governed system: inputs, validation, deterministic execution, and observability. Shopify Flow can help with merchandising operations (Shopify Help Center: Shopify Flow, accessed 2026-10-18)¹⁴, but only if you keep boundaries clear and don’t turn workflows into business-rule spaghetti.

What changes when we go multi-region?

Multi-region multiplies operational exceptions. If you duplicate logic outside Shopify, divergence becomes inevitable. Prefer Shopify-native regionalization for commerce truth, then layer experience differences where they’re cheapest to maintain.

How do we stop integration drift across systems?

Version your contracts, make idempotency non-negotiable for writes, verify and deduplicate webhooks, and run reconciliation. Then test the failures on purpose, as in the scenario above. This is an operations discipline, not a framework choice.

Where should we put “business logic” in 2026?

Put rule execution where it stays governed and upgradeable (Functions, where your plan allows), and keep experience logic close to the user interface. When business logic is scattered across storefront code, incident response becomes archaeology.

Recommendation

• If the trigger is a specific, rare failure, fix it and stop.
• If it’s promotions or checkout, move rule execution to Functions and UI to checkout extensions before anything else.
• If it’s integration reliability, build the verified, deduplicated, idempotent write path and its failure tests before you add another system.
• Consider headless only for an experience your theme can’t deliver, one path group at a time, with Shopify checkout kept and a rehearsed rollback.

Unresolved questions to answer for your store

• Which of your current customizations depended on Scripts or checkout.liquid, and have all of them been replaced?
• Which Admin mutations does your integration call, and which of them support the @idempotent directive on your API version?
• What is the system of record for customer, pricing, and inventory data, in writing?
• How much traffic do the pages you’d migrate get, and is it enough to measure a regression?

Next steps

Start with two artifacts from this guide: the readiness checklist and the decision matrix. They’ll tell you what to fix now without turning the year into a rewrite program. Then take the smallest move that resolves your current constraint.

For teams actively evaluating headless, keep the reading list short:

• The Ultimate Guide to Headless Shopify Development
• Advanced Headless Shopify Performance Techniques
• Shopify Hydrogen vs Liquid: When to Go Headless

If you want help with an architecture review or the integration work, see Shopify development.

How this was checked

Shopify platform facts (Scripts, checkout.liquid, REST status, Functions plan limits, webhooks, idempotency, rate limits, Storefront API scope) were checked against the linked Shopify documentation and changelog on 2026-10-18. The webhook handler was type-checked against the Cloudflare Workers types and exercised locally against signed test payloads the same day; it was not deployed to a real store. The contract, failure tests, decision matrix, and migration sequence are recommendations, not measured results.

Evidence Locker (Sources You Can Quote)