Para desarrolladores

Checkout agéntico, en cuatro llamadas.

Alyte es la capa de confianza que un agente supera antes de poder comprar. Te integras contra una API alojada, sin migración de pasarela, sin que el dinero nos toque. La misma ruta de solicitud ejecuta cada comprobación en el servidor, así que un agente no puede exceder su mandato sin importar lo que diga su prompt.

La integración

Discover, quote, reserve, confirm.

Una sola ruta de solicitud. Cada paso es una llamada REST normal con un token Bearer.

checkout.sh sandbox · sin tarjeta
# 1 · discover, inventario para el evento de un comercio
GET  /v1/merchants/mrc_42/events          Authorization: Bearer $TOKEN

# 2 · quote, fija el precio (devuelve un quote_id)
POST /v1/quotes          { "tier_id": "tier_ga", "qty": 2 }

# 3 · reserve, una reserva atómica, a prueba de sobreventa
POST /v1/holds           { "quote_id": "qt_9f3" }   Idempotency-Key: 3b1c…

# 4 · confirm, la propia pasarela del comercio liquida el cargo
POST /v1/holds/hd_7c/confirm   { "instrument": "inst_tok_…" }
discover quote reserve confirm El dinero se liquida del comercio a la pasarela del comercio. Alyte mueve solo instrucciones, nunca fondos.
Auth

Un token Bearer, con scope y ligado al tenant.

La parte importante: el límite de gasto se resuelve en el servidor a partir del registro del agente, nunca se lee del token.

Lo que envías

Una cabecera. Los scopes controlan cada ruta.

Authorization: Bearer <jwt>
scope: catalog:read payments:write agent:run
Lo que Alyte hace cumplir

El límite, el scope, la propiedad y las comprobaciones de sobreventa se ejecutan en el orquestador. El modelo no puede subir su propio límite de gasto; esa autoridad se resuelve en el servidor a partir del registro del agente.

cap → en el servidor, a partir del registro del agente
Superficies

Tres puertas de entrada. Un único marco de políticas.

REST, MCP y A2A pasan todos por el mismo orquestador, la misma auth, scopes, tenant, idempotencia y comprobaciones.

Honestos sobre la madurez: Las superficies y las verificaciones de políticas están activas y probadas. Los adaptadores de certificación de esquemas (TAP, Visa Intelligent Commerce) están conectados y aplicados en su forma, pero la verificación de firma en vivo y el agente de producción están en la hoja de ruta. El agente de sandbox se ejecuta como un script determinista. Etiquetamos real, simulado o stub con honestidad.

Garantías de la ruta del dinero

Idempotente por contrato. Tipado en el fallo.

Idempotency-Key

Se reclama de forma atómica antes de cualquier cargo, por tenant. Dos solicitudes concurrentes con la misma clave nunca autorizan ambas. Puedes reintentar libremente.

Idempotency-Key: 3b1c-…-9f
Taxonomía de errores estable

Códigos tipados, forma estable. Un resultado ambiguo de la pasarela detiene el proceso para reconciliar, nunca un rechazo silencioso que reintentarías hasta un doble cargo.

{ "error": { "code": "validation_error", "message": … } }
Lado de la oferta

Trae tu inventario y tu pasarela.

Las cuatro llamadas de arriba son el lado de la compra. Para que las entradas de un comercio estén disponibles para los agentes, se conectan dos cosas, ambas reales hoy, a través de la consola del comercio.

real · consola
Vinculación de la pasarela

Registra tus raíles de pasarela y guarda las credenciales como una referencia opaca, nunca el secreto, resuelta en el momento del cargo. Los cargos se liquidan en tu propia cuenta de pasarela. Alyte nunca es beneficiario.

credential_ref → resuelto en el cargo
real · consola
Catálogo

Crea eventos y niveles de entrada, fija precio y disponibilidad. El inventario mutable contra el que los presupuestos fijan el precio y que las reservas decrementan de forma atómica, la fuente de la garantía a prueba de sobreventa.

events · tiers · availableCount

Honestos sobre la API de oferta: La vinculación de pasarela y la gestión del catálogo están en vivo hoy en la consola del comercio, una superficie de administración que tú operas. Una API de sincronización de inventario servidor a servidor, para comercios con su propio sistema de ticketing que quieran enviar inventario mediante programación, más webhooks salientes (payment.succeeded, hold.expired), están en la roadmap, no lanzadas. Si tienes tu propia fuente de inventario, ese adaptador es lo próximo que construimos con socios de diseño.

Lee la documentación completa.

La guía rápida, la especificación OpenAPI legible por máquina, el SDK preliminar y la referencia completa de endpoints y errores llegarán a un sitio de documentación alojado. Mientras tanto, habla con nosotros y te guiaremos por la API directamente.

Habla con nosotros Probar el sandbox