简体中文
Storefront

Third-party Storefront

Build an independent storefront while preserving Ayalink identity, access policy, cache, and challenge boundaries.

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;
  • 429 or CHALLENGE_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.

Copyright © 2026