Skip to main content
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, 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 →

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 →

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 →

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 →

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 →

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 →

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 →

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 →

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