Push Nativo Personalizado
Integrar un proveedor personalizado de Notificaciones Push Nativas como parte de tu API del Operador
Fast Tracks soporta Firebase como proveedor de Notificaciones Push Nativas, si tu negocio necesita un proveedor que no sea parte de la lista de proveedores soportados entonces puedes construir esta API.
Servicio de Notificaciones Push Nativas de Fast Track
El servicio de Notificaciones Push Nativas de Fast Track puede ser configurado para enviar solicitudes de Notificaciones Push Nativas a los endpoints de la API del Operador listados abajo, lo cual permite al Operador gestionar el proveedor de Notificaciones Push Nativas. Soporta el envío de mensajes y obtener el estado de entrega. El envío está disponible tanto para solicitudes individuales como por lotes de Notificaciones Push Nativas.
Los siguientes endpoints pueden ser construidos como parte de tu API del Operador:
⬆️ POST /channels/push/single
⬆️ POST /channels/push/batch
El Operador puede entonces reenviar estas solicitudes al proveedor de Notificaciones Push Nativas para su procesamiento y responder con las respectivas respuestas.
El formato de la API y las respuestas necesitan ser formateadas como se describe a continuación
Es importante que los datos "meta" descritos a continuación sean enviados de vuelta a Fast Track ya sea por Webhook o Polling para que los datos de conversión puedan ser almacenados correctamente. Por favor consulta los ejemplos mostrados y las tablas debajo para mayor clarificación.
Pre-Requisitos
- Avisa a Fast Track si alguna limitación de tasa debe ser tomada en consideración. (Si planeas implementar limitación de tasa por favor contacta a Fast Track antes, para que podamos guiarte en la implementación soportada)
- Avisa a Fast Track si algún máximo de lote debe ser tomado en consideración.
- Proporciona a Fast Track cualquier credencial específica para los proveedores integrados (si es requerido)
Enviar Notificación Push Nativa (Individual)
Una solicitud de envío individual de Notificación Push Nativa contendrá los datos de cada Notificación Push Nativa individual en solicitudes separadas a la API.
Implementación del Endpoint
Implementa el endpoint en el formato de abajo para soportar Notificaciones Push Nativas de envío individual a través de la API.
⬆️ POST <operator-api-endpoint-url>/channels/push/single
Cabecera de Solicitud
La cabecera de la solicitud enviada contiene un "X-Api-Key" que es un token requerido para autenticar las llamadas de la API en el endpoint. Este token necesita ser pasado a Fast Track para hacer estas solicitudes.
Esquema del Cuerpo de Solicitud
Consulta el siguiente ejemplo de una solicitud individual de Notificación Push Nativa enviada por Fast Track. La descripción de cada campo está listada en la tabla debajo de este.
| Clave | Tipo | Descripción |
|---|---|---|
activity.id | integer | Un identificador único de la Notificación Push Nativa |
activity.brand_id | integer | El identificador único de la marca en Fast Track |
activity.user_id | string | El identificador único del jugador |
activity.activity_id | integer | El identificador único de la actividad configurada en Fast Track |
activity.action_group_id | integer | El identificador único del grupo de acciones del cual se origina la Notificación Push Nativa de Fast Track |
activity.trigger_hash | string | Hash del disparador |
activity.action_id | integer | El identificador único de la acción individual de Fast Track |
Respuestas Esperadas
La API del Operador debería retornar las respuestas para cada mensaje individual de Notificación Push Nativa respectivamente para evitar el almacenamiento no relacionado de datos de Notificaciones Push Nativas.
Exitosa Respuesta JSON HTTP 200-299
El push_id será un identificador único generado por la API del Operador que permite a Fast Track identificar ese mensaje particular de Notificación Push Nativa para actualizar su estado de entrega después de que sea enviado.
ERROR Respuesta JSON No-200
Las respuestas erróneas están típicamente asociadas con códigos de estado HTTP 400s o 500s. La respuesta debería contener un campo "error" con una descripción para mostrar qué salió mal y ayudar con la resolución de problemas.
Las respuestas de la API del Operador serán manejadas de manera diferente dependiendo de la clase del código de estado HTTP. La tabla de abajo da un resumen de cómo los estados HTTP son manejados por separado.
| Códigos de Estado HTTP | Descripción |
|---|---|
200-299 | Entregado Exitosamente. Fast Track reconocerá el mensaje y comenzará a procesar el siguiente mensaje en la cola. |
400-499 | No Exitoso. Al recibir este error, Fast Track omitirá el mensaje de Notificación Push Nativa. Adicionalmente, enviará sus datos a Acciones Fallidas, si el servicio está habilitado. |
500 o cualquier otro código de estado que no esté listado arriba | No Exitoso. El servicio falla y Fast Track seguirá reintentando hasta que se reciba una respuesta 200. |
Notificaciones Push Nativas por Lotes
Las Notificaciones Push Nativas por lotes ayudan a procesar una colección de Notificaciones Push Nativas en una solicitud a la API. El número de mensajes dentro de la solicitud por lotes está limitado por una cantidad entera establecida en la configuración y enviado dentro de un lapso de tiempo configurado, incluso cuando el lote aún no está lleno.
Implementación del Endpoint
Implementa el endpoint en el formato de abajo para soportar Notificaciones Push Nativas de envío por lotes a través de la API.
⬆️ POST <operator-api-endpoint-url>/channels/push/batch
Cabecera de Solicitud
La cabecera de la solicitud enviada contiene un "X-Api-Key" que es un token requerido para autenticar las llamadas de la API en el endpoint. Este token necesita ser pasado a Fast Track para hacer estas solicitudes.
Esquema del Cuerpo de Solicitud
Aquí hay un ejemplo del formato esperado al agrupar las solicitudes por lotes. Es similar a la solicitud individual de Notificación Push Nativa pero las solicitudes están almacenadas en un array, una tras otra.
| Clave | Tipo | Descripción |
|---|---|---|
activity.id | integer | Un identificador único de la Notificación Push Nativa |
activity.brand_id | integer | El identificador único de la marca en Fast Track |
activity.user_id | string | El identificador único del jugador |
activity.activity_id | integer | El identificador único de la actividad configurada en Fast Track |
activity.action_group_id | integer | El identificador único del grupo de acciones del cual se origina la Notificación Push Nativa de Fast Track |
activity.trigger_hash | string | Hash del disparador |
activity.action_id | integer | El identificador único de la acción individual de Fast Track |
Respuestas Esperadas
Las respuestas de abajo deberían ser retornadas por la API del Operador.
Exitosa Respuesta JSON HTTP 200
El "activity.id" inicialmente enviado en la solicitud será retornado de vuelta en la respuesta como "id". Esto es requerido para ayudar a Fast Track a identificar el mensaje individual de Notificación Push Nativa en la solicitud por lotes inicial.
El push_id será un identificador único generado por la API del Operador, que Fast Track usará para identificar el mensaje relacionado de Notificación Push Nativa al actualizar su estado.
Si cualquiera de las categorías listadas ("successful", "failed" o "fatal") no tienen una Notificación Push Nativa asociada, deberían ser retornadas como un array vacío.
La solicitud necesita incluir una de las propiedades successful, failed o fatal
El flujo lógico de cómo la respuesta será manejada es muy similar a cómo los códigos de estado HTTP son manejados en la Notificación Push Nativa Individual. La única diferencia es que la respuesta con código de estado 200 será manejada en su lugar, de acuerdo a la categoría del mensaje en la resp