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

## November 2026

### SDK 0.8.0: ticket limits, baskets, queue place and bank-challenge continuation

`@alytegen/sdk` 0.8.0 is on npm. `AlyteMerchant` gains `setEventPurchaseLimit`,
`getEventPurchaseLimit` and `clearEventPurchaseLimit` for the
[ticket limit per customer](https://alyte.mintlify.site/guides/purchase-limits.md), and `createPool({ externalRef })` so a
retried pool create returns the pool you already made (`existing: true`) instead of a second one;
`POST /v1/integration/events` and `/tiers` accept the same `externalRef`. `AlyteAgent` gains the
basket methods `reserveBasket`, `getReservation`, `quoteReservation`, `confirmReservation`,
`releaseReservation` and `resolveBasketSca` over `/v1/reservations/*`: several ticket types held
all or nothing and paid with one charge; the SDK returns the documented `402` basket outcomes as
values rather than throwing. The browser entry (`@alytegen/sdk/browser`) adds `watchCapabilities`,
`createWatch`, `getWatch` and `observeWatch` (a buyer's place in line and price-target watches),
and `openChallenge`, `purchase`, `resumePurchase` and `cancelPurchase` for shops that will ask the
buyer to authenticate the agent's purchase itself; that server-side setting is not enabled on
sandbox yet, so those calls are typed but inert today. Live on sandbox since revision
`alyte-sandbox-00145-gj5`.

### Adjust stock by a change, not a new total

If you also sell on your own checkout, send each change as an adjustment:
`POST /v1/integration/tiers/{id}/stock` with `{ requestId, delta }`. Alyte applies it to its own
count in one step, so tickets agents are holding stay held; writing a new `availableCount` would
put them back on sale. Resending the same `requestId` is safe. Short stock returns
`409 stock_insufficient` with the count Alyte has. On a pooled tier the change applies to the
pool. Live on sandbox since revision `alyte-sandbox-00137-x9w`.
[Inventory & fulfilment →](https://alyte.mintlify.site/guides/inventory-and-fulfilment.md#adjust-stock-when-you-sell-elsewhere)

### Ticket limits recognise cards, and count queued purchases

The ticket limit per customer now also recognises a customer by card: two buyer accounts paying
with the same card count as one. Stripe cards work with no setup; for Adyen, turn on **Include
alias info** in your Customer Area. Queued purchases now count while they wait (set
`countWaitingWatches: false` to switch that off), queueing over the limit is refused, and a watch
held back only by the buyer's own unpaid tickets keeps waiting instead of failing. Live on sandbox
since revision `alyte-sandbox-00137-x9w`. [Ticket limits per customer →](https://alyte.mintlify.site/guides/purchase-limits.md)

### Ticket limits per customer

You can now limit how many tickets one customer holds or buys for an event, across every agent and
queued purchase: `PUT /v1/integration/events/{id}/purchase-limit` with
`{ maxPerCustomer, maxHeldPerCustomer? }`. The optional `maxHeldPerCustomer` caps the unpaid
tickets one customer can hold at once. The first limit on an event counts the tickets already sold.
Agents see `purchaseLimit` in discovery, and a purchase over the limit gets
`409 purchase_limit_exceeded`, `409 held_limit_exceeded` or `409 purchase_limit_identity_required`;
nothing is held or charged. A customer is recognised by their Alyte buyer account for now. Live on
sandbox since revision `alyte-sandbox-00136-h2z`. [Ticket limits per customer →](https://alyte.mintlify.site/guides/purchase-limits.md)

### An agent without a mandate is refused, not challenged

A confirm from an agent with no spending authority (no permission from the buyer, no spend
cap) now returns `422 mandate_invalid` before anything is charged. It used to return
`202 sca_required` with a challenge the agent could answer itself. Production also refuses a
bank challenge that Alyte cannot verify yet (`422 sca_unavailable`). Agents acting under a
buyer's permission are unaffected. Live on sandbox since revision `alyte-sandbox-00135-s92`.
[Agent buy →](https://alyte.mintlify.site/guides/agent-buy.md)

### Hosted-checkout shops answer 409; checkout retries are safe

Reserving at a shop that sells only through its own checkout page returns
`409 hosted_checkout_required` with `details.checkoutUrl`, instead of a `500`. `POST /v1/checkout`
now honours `Idempotency-Key`: retrying with the same key returns the original payment instead of
charging again. Live on sandbox since revision `alyte-sandbox-00135-s92`. [Errors →](https://alyte.mintlify.site/guides/errors.md)

## October 2026

### SDK 0.7.0: early access and membership

Shops can open a tier early for their members at chosen levels, for holders of a card scheme, or
for everyone, ahead of general sale. Alyte checks eligibility itself on every purchase step.
`@alytegen/sdk` 0.7.0 adds `accessRules` (`list`, `get`, `createDraft`, `updateDraft`,
`preview`, `schedule`, `cancel`) and `memberships` (`createProgram`, `upsert`). Owners get the
same flow in the console under **Access rules**. An agent that tries too early gets
`409 access_waiting` with a `retryAfter`. Live on sandbox since revision
`alyte-sandbox-00133-v77`. [Early access and membership →](https://alyte.mintlify.site/guides/access-rules.md)

### Buyer pages show the venue's time zone

Order cards, event selectors and on-sale messages now show times in the event's pinned venue
time zone and name it, so a buyer elsewhere sees the right day. Public discovery adds the pinned
venue's name and time zone to each event.

### SDK 0.6.0: shared pools and venue locations

Several ticket types can now draw on one capacity (a **pool**), and an event can be pinned to a
versioned **venue location** with its own time zone. `@alytegen/sdk` 0.6.0 adds `createPool`,
`listPools`, `updatePool`, `createLocation`, `listLocations`, `updateLocation`, `getSlot`,
`setSlotLocation`, `createEvent({ location })` and a read-only `inventoryCatalog` observation.
Shop owners get the same controls in the console under **Inventory**. Live on sandbox since
revision `alyte-sandbox-00132-9ts`. [Shared inventory and locations →](https://alyte.mintlify.site/guides/shared-inventory.md)

### Event creation refuses unknown fields

`POST /v1/integration/events` now returns `400` for any field other than `merchantId`, `title`,
`startsAt` and the optional `location`; extra fields used to be ignored. The SDK and integrations
that send only those fields are unaffected. `startsAt` still needs an explicit offset.

### Adyen connections: keys tested on save, origins spelled out

Linking or editing an Adyen connection with a new API key now makes one read-only call
to Adyen first. A key Adyen refuses is not saved: the console and
`POST /v1/integration/merchants/{id}/psps` answer `422 psp_credentials_rejected` with the
reason; a verified key reports `credentialCheck: { "status": "verified" }`, an unreachable
Adyen saves the key and reports `unverified`. A card setup against a key Adyen refuses now
fails with `409 capture_unavailable` and tells the buyer the shop must update its
credentials, instead of a retryable `502`. The new guide explains the two origin lists
(your embed origins in Alyte; Alyte's origin in the Adyen credential), the signed webhook
and the test cards. Live on sandbox since revision `alyte-sandbox-00122-9j8`.
[Connect Adyen →](https://alyte.mintlify.site/guides/connect-adyen.md)

### 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 →](https://alyte.mintlify.site/guides/chat-consent.md)

### 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 →](https://alyte.mintlify.site/guides/getting-access.md)

### 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 →](https://alyte.mintlify.site/guides/console-api-keys.md)

### 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 →](https://alyte.mintlify.site/guides/console-api-keys.md)

### 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 →](https://alyte.mintlify.site/guides/errors.md)

### 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 →](https://alyte.mintlify.site/guides/chat-consent.md) ·
[Browser access and CORS →](https://alyte.mintlify.site/guides/browser-api.md)

### 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 →](https://alyte.mintlify.site/guides/embedded-authorize.md)

### 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 →](https://alyte.mintlify.site/guides/buyer-sessions.md)

### 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 →](https://alyte.mintlify.site/guides/buyer-sessions.md)

### 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 →](https://alyte.mintlify.site/guides/quickstart.md)

### 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 →](https://alyte.mintlify.site/guides/errors.md)

### 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 →](https://alyte.mintlify.site/guides/agent-buy.md)

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