Development and integrations

Use metafields to extend a resource with additional values. Consider a metaobject for structured content with multiple fields or reusable references, then define how the theme and APIs read it.

• Specify types, units, language and owners.
• Test references and missing values with real records.

Admin data is not automatically public storefront content.

Keep shared facts at product scope and option-dependent facts with the actual variant. Define ownership, types and units before checking which resource the theme and API read.

• Compare two variants with a real difference.
• Check missing values, defaults and selection changes.

Admin storage does not establish public output, and defaults must not conceal variant differences.

Assign an owner to the source record and reference the applicable information from product, collection, support and summaries. List affected surfaces and compare visible content, APIs and markup after a change.

• Connect models, markets and policy versions.
• Trace one change through all consumers.

Shared data must preserve model, market and version exceptions.

Record locked dependencies, framework and build entry. Hydrogen 2026-10 is composed into an app whose framework owns server entry, routing and builds. Scope a legacy migration from its actual starting point.

• Record Hydrogen, Remix or React Router, and the deployment version.
• Map effects on routes, cart, accounts and SEO.

Apply this check to Hydrogen storefronts; theme projects have their own boundaries.

Specify data inputs, merchant controls, missing-value behavior, languages and mobile presentation. Test real products and dynamic sources before extending reuse.

• List fields, editing boundaries and fallbacks.
• Compare output on preview and public routes.

Template reuse does not ensure every product has the required data.

Identify the assigned template, field definition, actual resource value and connected dynamic source. Compare populated and missing-value products to separate data, scope and rendering failures.

• Check the field types the block supports.
• Validate the agreed fallback or hidden state.

Preserve configuration and examples before code changes; duplicated templates do not resolve unclear data ownership.

Agree which system owns each product, inventory, price and order field, then verify the caller, allowed scope and write direction. A successful response still needs a resource-level and business-result check.

• Record field ownership, update direction, exception owners and audit evidence.
• Test permitted operations, denied operations and expired access.

Browser identity, app identity and Admin API access are different concerns. Use an authorized test environment for validation.

Assign source systems, stable identifiers and status meaning per product, inventory, customer and order. Define directions, conflicts and reconciliation, retaining transport and business completion separately.

• Trace one order across the connected systems.
• Define handling for delay, duplication and manual correction.

Different resources can have different owners; a later write should not silently resolve an unexplained conflict.

Verify the source and identify repeated deliveries. Keep business operations idempotent beyond the receipt counter, check current resource state when ordering matters, and reconcile to find missed processing.

• Record resource IDs, delivery IDs, processing state and failures.
• Check whether the business action already happened before replaying it.

Receiving a delivery, completing a task and reaching a consistent business result are separate states. Define recovery with the other system.

Fix one product and variant, then test first entry, return after a market change and product or API failure. Compare initial HTML, visible state, currency, availability and cart, retaining response and recovery evidence.

• Record the visit and switching sequence.
• Check isolation between accounts, carts and public products.

A cache hit or speed run does not establish correct market data.

Use the same market, product and variant in preview, after the production switch and after restoring a previous deployment. Record deployment, variable versions, cache and service dependencies, then recheck purchasing after recovery.

• Check domains and data sources for preview and production.
• Recheck product, cart and checkout handoff after recovery.

Oxygen deployments retain their deployed variable values; changes require redeployment. This checklist is not evidence of a completed client exercise.

Hand over versions, configuration and access ownership, release recovery and known issues. Have the receiving team perform a controlled check, recording code delivery, deployment and business acceptance separately.

• Record environments, interface versions and change owners.
• Check that monitoring, backups and recovery routes are usable.

Documentation and demonstrations do not establish that a production recovery exercise was completed.