Third-party Storefront
Third-party Storefront
Public catalog reads use the API-selected store, market, and publication state. A custom domain must not infer access from a product ID, slug, search result, cached JSON-LD, sitemap, or OpenGraph response.
Hosted redirect model
flowchart LR
A[Third-party store: read and render the public catalog] --> B{User action}
B -->|Sign in or register| C[Official Ayalink authorization domain: not yet available]
B -->|Checkout or pay| D[Official Ayalink hosted checkout: not yet available]
C --> E[Reviewed exact return URL]
D --> E
E --> A
- Catalog reads: Available. Call only operations listed in the Third-party Storefront public API.
- Hosted sign-in/registration: Not yet available. The current artifact has no authorization endpoint or official URL, so there is no executable redirect example.
- Hosted checkout/payment: Not yet available. The current artifact has no checkout/payment endpoint, order intent, or return protocol, so there is no executable redirect example.
- Return: Platform enablement required. A future flow may return only to an exact HTTPS return URL reviewed by the platform; no open redirect or client-side override is allowed.
A third party must not collect an Ayalink email, password, or MFA; accept or forward the global Ayalink Cookie; handle card data, payment tokens, or any other payment credential; or iframe, proxy, or imitate an Ayalink sign-in, registration, checkout, or payment page. The third-party site renders the catalog and initiates only a future top-level redirect approved by a public contract.
When a store protects a page or resource, the API applies the same policy to details, prices, inventory, media, structured data, SSR, search, sitemap, and cache. Handle:
401: send the user through system-domain OAuth and return to an allowlisted local route;403: the authenticated user lacks the required membership, role, customer group, market, or scope;404: the store chose anti-enumeration semantics for a hidden resource;429orCHALLENGE_REQUIRED: render a scoped challenge and retry the original request once.
Cache public responses only by the complete server-declared key, including store, market, language, policy version, and authentication class. User-specific responses are private/no-store and must never enter a shared CDN cache.
The browser never receives a client secret or stores an access or refresh token, and it must not proxy or share the Ayalink global-session Cookie. Future sign-in occurs only on the official authorization domain confirmed by platform enablement materials, using Authorization Code with PKCE S256, an exact redirect URI, state, and nonce.
Use a same-origin BFF for a durable session. It stores only the minimal OAuth grant for its own app, installation, store/resource, and audience, then gives its frontend a secure application-session Cookie. It never forwards an Ayalink Cookie. OAuth APIs are pending security review, so the account authorization boundary and minimal Nuxt example provide no sign-in endpoint or token-exchange code.
Enterprise integration journey
An end-to-end path from readiness and platform enablement through authorization, API use, Webhooks, testing, production, and emergency revocation.
Turnstile trust boundary
Limit Turnstile to bot protection on official sign-in and authorization endpoints, not proof of site authenticity or login.