Shopify / Google integration on an AEM scaffold — via Webflow export

What this is: how the Shopify + Google integration ships onto an Adobe Experience Manager estate, using the Webflow export as the page scaffold.

What you can decide after reading it: whether to adopt the scaffold path, and which substrate election (Cloudflare or Adobe/Azure) your paper already supports.

Companions (referenced, not restated): the trust framework, Cybersecurity for AI, and the key ceremony.

1. Premise

AEM owns the glass: content authoring, templates, Adobe-managed delivery. It never holds identity, consent, or commerce credentials.

The integration ships beside it, never inside it — a substrate AEM does not have and was not built to have:

Rows decide. The gate serves. The ledger remembers. JWKS verifies.

That grammar appears once in this doc, here. Every section after this one is an application of it.

Declared non-goal, up front: this is not an ESB replacement. It can feed an existing ESB; it does not duplicate one (§8).

2. The scaffold pipeline — Webflow → vanilla export → AEM

Webflow (author)  →  vanilla HTML/CSS export  →  AEM templates + clientlibs  →  embeds layer on

The load-bearing claim: behavior never lived in the Webflow runtime, so the export loses nothing. Interactions, CMS bindings, and Webflow.js were never load-bearing; all app behavior is served from worker-hosted embeds that are framework-agnostic by construction. The export is markup and stylesheet — exactly the two things AEM wants to own as content.

Rule carried over from every other surface: embed, not iframe. The blocks mount on the host page's origin, because the session contract (§5) reads first-party storage.

Invariant this section ends on: the scaffold is disposable; the embeds are not. Re-export, re-theme, or rebuild the AEM templates and nothing security-relevant moves.

3. The Shopify socket

Hard precondition — the consent bridge. AEM is a headless surface, and every headless surface wires setTrackingConsent before any tracking or cart call. No consent signal, no fire. This is the one integration step that is not optional and not deferrable.

Invariant: no Shopify credential is ever present in AEM, the page, or the transport. The socket terminates in Xano; the page sees only its own session.

4. The Google socket

Boundary statement: analytics reads, never decides. BigQuery and predicted-LTV modeling sit downstream of the ledger and stay off the authorization path. Nothing in the analytics plane can grant, revoke, or transact.

5. The substrate contract — what AEM doesn't have

Three pieces, identical on AEM, Shopify, Webflow, or a packaged PWA:

• Session contract. Three keys — token, timestamp, user — plus one change event the embeds broadcast and subscribe to. Any surface that can hold first-party storage can hold a session.
• Entitlement rows. A grant is a row: subject × capability × asset. Grant = insert. Revoke = delete. Audit = SELECT. Agents are first-class subjects under scoped, revocable mandates — the same row shape as a human.
• Verification. Proofs verify against /.well-known/jwks.json on the customer's own domain.

Invariant: the JWKS endpoint is the piece that never moves — not in a re-platform, not in a substrate election, not in a vendor exit.

6. Substrate election — either/or, never hybrid

The identical grammar runs on either substrate. An enterprise picks one; it is a decision, not a migration project.

Procurement reading of that table: almost every row lands on paper that already exists — the Adobe bundle, the Azure commitment. The one new agreement is the Fastly Compute + Secret Store service. The proofs row needs no paper at all.

EdDSA is substrate-neutral: certificates minted on either edge verify with the same client code. The kid is the only trace of which edge signed.

7. Delivery phases

Phase 4 is deliberately last and deliberately optional: the election changes where the gate runs, not what the system does.

Demonstrated — phases 1–3 on a live AEMaaCS tenancy

Run on 2026-08-02 against an AEM as a Cloud Service environment (Edge Delivery + Universal Editor, xwalk boilerplate). Not a mockup — the adoption path above, executed:

• Scaffold (§2): the point-of-difference card grid — the same section that runs on the Shopify store and the Webflow site — shipped into the AEM repo as a block (markup, CSS, and a three-field content model), appeared in the Universal Editor's component palette, was authored as content, and published through Edge Delivery.
• Substrate (§5): stack-loader.js first in the page head, footer embed deferred. On the AEM origin, the worker injected the footer, the login host, and the consent banner (Accept All / Customize / Reject); the session-contract and modal APIs came up; the brand plane served the theme CSS and self-hosted fonts. Tenant resolution came from one origin-to-shop pair on the worker.
• Identity (§5), signed in: a real login on the AEM origin — the account menu and the Choose-your-view role picker (CISO/DPO, Designer, Revenue BA, QA/Compliance, Release Manager…) rendering as a headless modal on Adobe's glass. Separation of duties, served by the worker, no AEM-side identity anywhere:

• Boundary held: no AEM credential, key, or secret exists anywhere in the exchange. The environment was a stock 30-day trial; everything durable lives in git.

For comparison, the same section on the Shopify store:

8. Boundaries

• No standing credentials in AEM, the page, or the transport. There is nothing in the middle worth taking; relays and CDNs are verifiably empty.
• AI Data Transport, not an ESB. An ESB holds standing credentials to every connected system and orchestrates messages between them. This holds none, dissolves authority into individually revocable rows, and can feed an ESB that already exists.
• AEM authors content. It never authors identity.

Appendix — glossary