Acreditación de Bonos
Los endpoints para soportar el Acreditado de Bonos son necesarios para soportar la integración básica de Fast Track. Las instrucciones sobre cómo enviarlos se listan a continuación.
El Servicio de Bonos está diseñado con semánticas de entrega "al menos una vez".
Esto significa que el servicio siempre intentará enviar cada evento de bono al menos una vez. Por ejemplo, si la API del Operador responde con un error 500, el Servicio de Bonos reintentará enviar el evento hasta que tenga éxito.
Para asegurar idempotencia en su extremo, recomendamos usar el encabezado x-fasttrack-id incluido en cada solicitud enviada por Fast Track.
Este encabezado proporciona un identificador único para cada evento de bono, permitiéndole manejar de manera segura los reintentos sin duplicar el procesamiento de bonos.
⬆️ POST /bonus/credit
El Operador necesita proporcionar a Fast Track el endpoint de Acreditado de Bono para asegurar que FT CRM pueda automatizar el acreditado de bonos.
Esto debe activar inmediatamente o hacer que el jugador sea elegible para el bono. Esto depende de cómo el Operador está manejando las interacciones de bonos con sus jugadores.
Notas
- ej. Si el jugador necesita optar por participar en el sitio para el bono, este endpoint debe hacer que el jugador sea elegible para optar por participar. El resto de la lógica debe ser manejada por el Operador
- Se pueden agregar nuevos campos para ser pasados al Operador (ej. validity_amount) desde el FT CRM.
Solicitud
Código de Respuesta
200 OK - FT recibió reconocimiento de la API del Operador que el bono ha sido aceptado.
40X ERROR - Esto significa que la api del operador ha respondido, sin embargo no puede acreditar el bono al jugador. Esto se clasifica como Acciones Fallidas.
50X ERROR - Este es un error de servidor, la api del operador no está respondiendo. FT continuará intentando acreditar el bono con el mecanismo de reintento incorporado de FT. Por favor refiérase a la verificación de idempotencia descrita en la parte superior de la página.
⬇️ GET /bonus/list
Este endpoint puede ayudar a mejorar el flujo de configuración de campañas de bonos cargando una lista de los bonos disponibles del operador. Este menú desplegable puede agregarse manualmente en la back-office en cualquier momento seleccionando Menú Desplegable Dinámico en las configuraciones de campo.
Respuesta
Los payloads son sensibles a mayúsculas, por favor asegúrese de que el payload se alinee con el ejemplo a continuación.
200 OK
ERROR
⬆️ POST /bonus/credit/funds
Este endpoint puede usarse para acreditar fondos inmediatamente a las billeteras del jugador.
Un ejemplo de uso es poder automatizar el acreditado de cashback.
Solicitud
Código de Respuesta
200 OK - FT recibió reconocimiento de la API del Operador que el bono ha sido aceptado.
40X ERROR - Esto significa que la api del operador ha respondido, sin embargo no puede acreditar el bono al jugador. Esto se clasifica como Acciones Fallidas.
50X ERROR - Este es un error de servidor, la api del operador no está respondiendo. FT continuará intentando acreditar el bono con el mecanismo de reintento incorporado de FT. Por favor refiérase a la verificación de idempotencia descrita en la parte superior de la página.
📈 Reportes de Bonos
Fast Track incluirá los encabezados a continuación en todas las solicitudes salientes contra su API del Operador. Estos deben almacenarse y enviarse de vuelta en los Eventos de Bonos, lo que permitirá al usuario final ver reportes sobre el costo de bonos para cada campaña en Fast Track Data Studio.
Descripción de cada encabezado:
X-Fasttrack-Actioncommunicationprofileid = Perfil de Comunicación (traducción) usado
X-Fasttrack-Actiongroupid = El grupo de acciones que contiene las acciones
X-Fasttrack-Actionid = Id de la acción (ej. Enviar SMS o Acreditar Bono)
X-Fasttrack-Activityid = Id de la actividad en sí
X-Fasttrack-Id = Id único por disparador, por usuario
X-Fasttrack-Triggerhash = El Triggerhash se usa para identificar un envío único del mismo evento. es decir, solo deberías tener una acción recibida con los mismos: activity_id, action_id, user_id, y Triggerhash. Si usas una actividad basada en tiempo para dirigirte a digamos 100 jugadores, todos esos 100 jugadores tendrán los mismos activity_id, action_id, y Triggerhash.