Skip to main content
En VENTRY hay dos operaciones distintas en la puerta, y probablemente necesites las dos:

Acreditación

Sucede una vez por asistente. Se lee el QR de la entrada y se le vincula una pulsera física. A partir de ahí, la pulsera es su identidad.

Control de zona

Sucede cada vez que alguien cruza una puerta interior. Se lee sólo la pulsera y se comprueba si puede pasar a esa zona.
Permisos necesarios: checkins.write (requiere activación manual) y, para consultar el histórico, checkins.read.
Estas llamadas van desde tu servidor, nunca desde la aplicación de puerta directamente. Una API key incrustada en una app móvil está, a efectos prácticos, publicada. Que tu app hable con tu backend y sea éste quien llame a VENTRY.

Acreditación

El operario escanea el QR de la entrada y después la pulsera nueva:
La pulsera nace con las zonas del tipo de entrada más las extra_zones de esa entrada concreta, y con sus días de validez. No hay que configurarla: todo sale de la entrada.
Manda la firma de originalidad aunque no verifique. Se guarda igualmente, y es lo que permite auditar después qué parque de pulseras entró realmente al evento.

Reintentos

La Idempotency-Key identifica el escaneo físico. Genérala al leer el QR y consérvala durante todos los reintentos de esa acreditación:
Si la red se corta justo después de que VENTRY canjee la entrada, el reintento devuelve la misma pulsera en lugar de emitir una segunda.

Qué puede salir mal

Doble acreditación. Cuando dos puertas intentan acreditar la misma entrada, sólo una gana. La segunda recibe 409 ticket_already_claimed y la pulsera que se acaba de emitir queda en estado pending_review: se puede escanear —para que seguridad se entere— pero no gastar saldo.VENTRY no decide a ciegas cuál es la buena: puede ser el mismo operario reintentando en otra puerta, o un QR duplicado. Lo resuelve un supervisor desde el panel. Tu aplicación debe mostrar el mensaje y pedir que avisen a un responsable, no reintentar.

Control de zona

El operario escanea sólo la pulsera, en la puerta de una zona interior:
Denegar no es un error. La respuesta es siempre 200, con allowed: true o false y el motivo. Un 403 significaría que tu API key no tiene permiso, que es otra cosa completamente distinta: si mezclas ambos casos en el mismo catch, acabarás denegando accesos legítimos cuando caduque tu clave.
Motivos de denegación que verás: Cada llamada queda registrada en el histórico de escaneos, así que la operación aparece en las estadísticas del organizador atribuida a tu integración.

Consultar el histórico

Implementación de referencia