En esta página
Configure un receptor en su backend
Indique callback_url al crear la transacción para definir su destino. Si se omite, se utiliza el webhook configurado en el Tenant. El receptor debe admitir el formato documentado y conservar los bytes recibidos antes de interpretar JSON.
El payload incluye api_version, event_id, event_type, created_at y transaction. Los headers X-Face-Auth-Event-Id, X-Face-Auth-Event-Type, X-Face-Auth-Timestamp y X-Face-Auth-Signature identifican y autentican la entrega. Consulte la referencia completa para los enums de eventos.
Una entrega puede repetirse
Deduplicar por transaction_id descartaría eventos diferentes del mismo recorrido. Utilice event_id con almacenamiento duradero y protegido frente a concurrencia. Valide la firma antes de confiar en el evento y compruebe la coherencia del identificador entre el envelope y el header.
El receptor puede guardar el evento validado en una cola duradera y procesarlo después. Responda con éxito solo tras aceptar el trabajo de forma persistente; una confirmación no debe ocultar pérdida de datos.
No dependa del orden de llegada
Un reintento o retraso puede entregar un evento antiguo después de uno más reciente. Consulte la transacción mediante GET para conciliar el estado antes de ejecutar efectos de negocio. Haga esos efectos idempotentes para evitar dos liberaciones ante un reintento.
Continúe con validación HMAC y reentrega y conciliación. Una integración lista también trata firmas inválidas, indisponibilidad temporal y eventos fuera de orden.