> ## Documentation Index
> Fetch the complete documentation index at: https://alyte.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 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 →](/guides/chat-consent)

### 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 →](/guides/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 →](/guides/console-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 →](/guides/console-api-keys)

### 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 →](/guides/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 →](/guides/chat-consent) ·
[Browser access and CORS →](/guides/browser-api)

### 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 →](/guides/embedded-authorize)

### 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 →](/guides/buyer-sessions)

### 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 →](/guides/buyer-sessions)

### 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 →](/guides/quickstart)

### 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 →](/guides/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 →](/guides/agent-buy)

### 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`.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.