What's new

Changes to the Alyte API and buyer pages that integrators should know about, newest first.

Entries below describe sandbox (https://app.alytegen.com) unless explicitly marked planned or not enabled.

October 2026

Inside your chat: compact chrome, a draft that survives closing

Framed by your page, the consent and authorize views drop Alyte’s own brand, account email and footer and show a small “Secured by Alyte” line. A setup the buyer has started survives closing the dialog — or your frame — and resumes where it was (kept per buyer, for a day); the consent view asks “Discard this setup?” before cancelling, so your cancelled event arrives only when the buyer confirms. If you omit font in a theme, the view keeps Alyte’s Hanken Grotesk; secondary text and dividers are derived from your palette with readable contrast. Live on sandbox since revision alyte-sandbox-00118-vmn. Chat guide →

Scopes: merchant:admin for shops and payment providers

Creating or deleting a shop and linking a payment provider now require the new merchant:admin scope; merchant:write keeps catalog writes, webhooks, buyer-session minting and the shop’s public settings. Every active key that held merchant:write was widened automatically, so existing integrations are unchanged. New keys get only what you ask for: choose the console’s full preset for a backend that creates shops. Getting access →

Console roles: owner and integrator

A merchant can invite a partner as an integrator: API keys (never merchant:admin, and it revokes only keys it minted), the shop’s embed origins (PUT /v1/console/merchants/{id}/embed-origins) and reads — never shops, payment providers, the catalog or the team. Console → Team → role integrator.

Console: attested consent in view, keys show last use

Settings shows what merchant attestation produced — whether it is on, the per-buyer ceiling, the attest keys, permission counts, buyers near the ceiling and the recent permissions (GET /v1/console/attested-consent). An owner can withdraw a permission its attestation created, with a reason (POST /v1/console/attested-consent/permissions/{id}/revoke); withdrawing never replenishes the rolling allowance. The API-key list shows when each key was last used (“No usage recorded” until a key-bound token has been used) and marks attest keys “attestation disabled” while staff have the capability off. Console and API keys →

Attest-only keys in the console

Enabled organizations can choose attest verified customers only in API keys. The key has only mandates:attest. If enablement is removed, the option disappears; a selected option is cleared and minting waits for an explicit scope choice. The API-key list now includes attestAvailable for the signed-in organization. Guide and REST example →

SDK 0.5.0 types the attested mint

buyerSessions.mint({ merchantId, email, merchantAttested: true }) is typed from @alytegen/sdk 0.5.0; the REST field was already accepted. Nothing else changes.

Withdrawn: the emailed consent confirmation announced as planned

An entry here earlier this month described a planned replacement of the verification code by an emailed link. That plan is withdrawn and will not ship. The current system is the system: enabled merchants attest within their ceilings; everyone else confirms the emailed code inside Alyte’s screen. Nothing in your integration changes.

Saved-card setup checks

Stripe card setup now verifies off-session setup and the card’s customer association before saving it. Retrying verification after a successful setup reuses that setup. card_preparation_unavailable is retryable; card_not_chargeable and card_customer_mismatch need the buyer to correct the saved-card setup. Errors →

Buy inside your chat with the browser SDK

@alytegen/sdk 0.4.0 adds @alytegen/sdk/browser: your page exchanges a minted session for a bounded bearer held in memory, opens Alyte’s consent view inline when the buyer needs an agent (verification and card entry happen inside it), and buys or queues within the permission — no redirect, no cookies. Sign-in and verification routes are refused to partner origins; the bounded bearer cannot create or widen spending authority. Details → · Browser access and CORS →

Up to three embed origins

embedOrigin accepts up to three bare origins (space- or comma-separated), so production and staging can both frame the authorize page and call the buyer API. http is accepted for localhost only. Details →

Attested consent for contracted merchants

Merchants Alyte staff enable under contract can mint with merchantAttested: true on a mandates:attest key: the buyer’s permission is created within staff-set ceilings without the emailed code and shows “Set up by shop”. Everyone else is refused with 403 merchant_consent_not_enabled. Details →

Buyers verify their email before granting an agent spending power

Sessions you mint with buyerSessions.mint are now bounded. They can act inside authority the buyer already granted, but saving a card, creating an agent, granting a mandate, changing an agent’s card or raising a card’s spending cap first needs a 6-digit code emailed to the buyer. The authorize page asks for it; your integration does not change. Test with inboxes you can read. Details →

Tier restrictions are accepted on create

POST /v1/integration/tiers now saves onSaleStart, onSaleEnd, maxQtyPerPurchase, sellable, allowedGeos and allowedSchemes in the same write as the tier. Unknown fields are refused with 400 instead of being dropped. Details →

The buyer pages speak six languages

The authorize page and buyer screens are available in English, German, Spanish, French, Hungarian and Brazilian Portuguese. Pass lang when you mint a session to choose one; otherwise the buyer’s own choice or browser language applies. The non-English text is a first draft pending native review: report anything that reads wrong.

Rate limits tell you when to retry

A 429 now carries code: "rate_limited", a retryAfter value in seconds and a matching Retry-After header. Errors →

Card setup accepts cards only

The card-capture step now offers card payment methods only. Saved cards are also tied to the shop and payment connection they were saved for; using one elsewhere is refused with 409 instrument_provider_mismatch.

Payments can be pending

Confirm can answer 202 when the shop’s payment provider confirms asynchronously. Do not submit the payment again; the purchase completes or is released when the provider’s confirmation arrives. Agent buy path →

Adyen (coming to sandbox)

Merchant setup can now hold an Adyen sandbox connection, and Alyte can save Adyen cards and complete Adyen purchases from verified provider evidence. It is not switched on in sandbox yet: Stripe remains the provider to test with.

Public SDK

@alytegen/sdk is on npm (MIT): npm install @alytegen/sdk.