Validation API — Guía para partners

Versión del protocolo: 1.0 · Estado: Draft · Audiencia: equipos técnicos de partners.

Crowder es la plataforma de ticketing sobre la que operan distintas ticketeras. Cuando una ticketera necesita validar un código que el comprador ingresa durante la compra (cupón, voucher, número de socio, código de invitación, etc.), puede delegar esa decisión a una API tuya. Vos —el partner— decidís si el código es válido; Crowder se encarga de llamarte y de aplicar tu respuesta al flujo de compra.

Lo que vas a construir

1. Un endpoint de validación (POST {baseUrl}/validate) que Crowder invoca para preguntarte si un código es válido. Se llama tanto cuando el comprador lo ingresa como al efectivizar la reserva.
2. Un endpoint de reversa (POST {baseUrl}/refund) (opcional) que Crowder invoca cuando se devuelve una compra, si llevás control de los códigos usados.
3. Un conjunto de datos de configuración que le entregás a la ticketera para que te dé de alta en su instancia de Crowder.

Autenticación

Si querés que tus endpoints requieran credenciales, definí una API key que Crowder enviará en el header apiKey de cada request:

apiKey: <tu_api_key>

¿Por qué `apiKey` y no `Authorization: Bearer`?

Si también integrás el producto Embedded App, vas a ver que ahí la API key viaja en Authorization: Bearer. La diferencia es intencional: son dos productos distintos, con vidas independientes y configuraciones separadas en Crowder. No asumas que la misma key funciona en ambos.

Estrategia de timeout

Crowder espera tu respuesta como máximo 10 segundos. Si no llega a tiempo, aplica la estrategia que dejaste configurada:

• Aceptar — continuar como si el código fuera válido.
• Rechazar — abortar como si el código fuera inválido.

Consejo

La estrategia se elige al configurar el validador. Elegila en función del impacto que tenga, para tu negocio, aceptar un código que tu sistema no llegó a validar.