Bring your own auth

Your users, your login, your database — Alyte only needs an attestation.

Your customers already have accounts with you. Alyte doesn’t replace your auth or your user database — it plugs into them.

​

How it works

1. A user is signed in on your site, with your auth.
2. They want an AI agent to buy tickets for them.
3. Your server attests them to Alyte (API token, merchant:write):

const s = await alyte.buyerSessions.mint({
  merchantId: 'mrc_…',
  email: user.email,
});
// → { buyerId: 'byr_…', redeemPath: '/buyer/redeem?token=…', expiresAt }

Optional fields open the page as a checkout for one ticket type: tierId, quantity (1–10, requires tierId), returnUrl (HTTPS, or HTTP on localhost and 127.0.0.1; under a registered embed origin when configured) and lang (a language tag such as de or pt-BR; the page also honours the buyer’s own choice and browser language).

Unknown fields and quantity without tierId return 400 validation_error with the field names in error.details.fields. returnUrl is a back link, not an automatic redirect.

4. You redirect the user to ALYTE_URL + s.redeemPath.
5. They arrive on the shop’s authorize page already signed in, and grant their agent a mandate: spending cap, validity window, optional event scope.

​

Your attestation is trusted for buying, not for granting

A session you mint is merchant-attested: Alyte believes your server that this is user.email, but nothing has yet shown that the person in the browser controls that inbox. So the session is bounded:

• It can act inside authority the buyer already granted: view their agents, mandates and purchases, and let an agent buy within an existing mandate.
• It cannot create or widen spending authority on your word alone. Saving a card, creating an agent, granting a mandate, changing an agent’s card, or raising a card’s spending cap first requires the buyer to prove they own the inbox.

On the authorize page this is one extra step, handled entirely by Alyte: when the buyer first tries to grant, the page shows Verify your email, sends a 6-digit code to the attested address, and continues once they enter it. The verified credential lasts 30 minutes; a code allows five attempts. Your server never sees the code or the resulting credential, and there is nothing to change in your integration.

What it means for you:

• Test with inboxes you can read. In sandbox the code is a real email. Automated browser tests that drive the authorize page must read that inbox, or stop before the grant step.
• A direct call to one of those buyer endpoints with a bounded session is refused with 403 step_up_required. That is the page’s cue to ask for the code, not an error to retry.

This is the ordinary identity-attestation path. The separately enabled contracted consent path below has its own authority and ceilings.

​

In a chat: exchange instead of redirect

A page on your registered embed origin can exchange the mint’s single-use token for a bounded bearer kept in memory, then open Alyte’s consent view inline and buy within the permission — no redirect, no cookies. The rules above are unchanged: the bearer is bounded, and creating or widening permission happens in Alyte’s view with the emailed code. See Buyer purchases inside your chat.

​

Contracted merchants: attested consent

Merchants under contract with Alyte can be enabled by Alyte staff to attest their customer’s consent themselves: a mint with merchantAttested: true, on an API key holding the dedicated mandates:attest scope, lets the buyer create a permission without the emailed code — within ceilings staff set for the shop (amount, currency, duration). The buyer sees “Set up by your shop” on that agent and can revoke it at any time. A grant outside the ceiling returns 403 merchant_consent_ceiling_exceeded; the buyer can use their own verification instead. Without the enablement the mint is refused with 403 merchant_consent_not_enabled. This is not available to agent operators; ask us when your contract is in place.

Choose attest verified customers only in the console’s API-key form. The key holds only mandates:attest, and read/write keys do not implicitly include it. @alytegen/sdk 0.5.0 types the field (buyerSessions.mint({ …, merchantAttested: true })); Console and API keys has the equivalent REST call.

​

Properties worth knowing

• Single-use, short-lived. The redeem link works once and expires in 15 minutes. Hashed at rest, rate-limited per email.
• Stable identity. buyerId is deterministic per email — a user who arrives via your attestation today and via the email magic-link fallback tomorrow is the same buyer, with the same agents and mandates.
• Tenant-locked. Your API token can only mint sessions into your own shops.
• The mandate is enforced by Alyte, not the agent. A prompt-injected or malfunctioning agent cannot exceed the cap or scope the buyer granted — every check runs server-side.

​

Fallback: magic link

No integration? Buyers can always use the shop page’s built-in email magic link. The attestation flow above is the same machinery with the email step replaced by your session — which is why the identities converge.