Eventos de Webhook
Puedes configurar webhooks a través de API que te permiten recibir notificaciones sobre eventos que suceden en tus tiendas.
Estos son los eventos disponibles para recuperar con webhooks:
NEW_ORDER
: Evento de creación de la ordenORDER_EVENT_CANCEL
: Eventos de cancelación de pedidos. Ver Eventos de cancelaciónORDER_OTHER_EVENT
: Otros eventos del pedido. Ver Otros eventosMENU_APPROVED
: Eventos de aprobación del menú.MENU_REJECTED
: Eventos de rechazo del menú.PING
: Este evento habilita el proceso de health checkSTORE_CONNECTIVITY
: Este evento habilita el proceso información de conectividad de las tiendas. (Cuando deja o vuelve a estar disponible para operar)ORDER_RT_TRACKING
: Este evento habilita el proceso de tracking.
Utiliza los endpoints Webhooks para registrar y probar webhooks en tus tiendas.
Importante
En caso de querer consultar las IP’s desde donde se envía la información, deberán preguntarle a su Project Manager
Payloads de los eventos de webhook
NEW_ORDER
El evento NEW_ORDER
va a enviar la misma información que podemos obtener del endpoint getOrders para la orden que dispara el evento. Podemos encontrar mas información del body en la API reference
ORDER_EVENT_CANCEL
El evento ORDER_EVENT_CANCEL
enviará el payload con el siguiente formato:
{ "event": "canceled_with_charge", "order_id": "106", "store_id": "900109448" }
Donde event representa el nombre del evento de cancelación.
Donde order_id representa el identificador de la orden.
Donde store_id representa el Identificador de la tienda en la aplicación de Rappi.
ORDER_OTHER_EVENT
El evento ORDER_OTHER_EVENT
enviará el payload con el siguiente formato:
{ "event": "taken_visible_order", "order_id": "344949817", "store_id": "10000682", "event_time": "2023-05-04 12:01:22", "additional_information": { "courier_data": { "id": 729365, "phone": "3118012176", "full_name": "Daletzi Karina Olmedo Plata", "last_name": "Olmedo Plata", "first_name": "Daletzi Karina", "profile_pic": null }, "eta_to_store": 147, "storekeeper_name": "Daletzi Karina Olmedo Plata" } }
Donde event representa el nombre del evento.
Donde order_id representa el identificador de la orden.
Donde store_id representa el Identificador de la tienda en la aplicación de Rappi.
Donde event_time representa el dia y hora de evento.
Donde additional_information representa información detallada de la orden.
MENU_APPROVED
El evento MENU_APPROVED
enviará el payload con el siguiente formato:
{ "store_id": "900109448", "message": "Menu Approved" }
Donde store_id representa el Identificador de la tienda en la aplicación de Rappi.
Donde message es el mensaje de aprobación del menú.
MENU_REJECTED
El evento MENU_REJECTED
enviará el payload con el siguiente formato:
{ "store_id": "900109448" }
Donde store_id representa el Identificador de la tienda en la aplicación de Rappi.
PING
El evento PING enviará el payload con el siguiente formato:
{ "store_id": 999 }
Donde store_id representa el Identificador de la tienda en la aplicación de Rappi.
La respuesta debe tener el siguiente formato:
{ "status": "OK", "description": "Tienda prendida" }
status: este campo es requerido, si viene null o con un valor distinto a OK se considerará que la tienda no está disponible.
description: este campo es opcional.
¿COMO FUNCIONA PING?
OBJETIVO
Detectar cuando una tienda pierde conectividad y apagarla al ocurrir un cambio de ping de positivo a negativo, con el fin de prevenir futuras cancelaciones por consecuencia de dicha falta de conectividad en la tienda para aceptar el take. Este Ping debe estar implementado para cada tienda y no en un servidor central como general.
FUNCION
El monitor recibe una notificación cada vez que una tienda pase de recibir ping positivo a negativo. Al darse esto, inmediatamente se envía a suspender la tienda en cuestión. Como administrador se puede configurar el número de strikes para aplicar las reglas de ping negativo.
- El ping, cuando se tiene configurado un webhook, se envía cada 3 minutos, en caso de no tener webhook y utilizar Pulling de ordenes, se evaluará cada 3 minutos.
- Dependiendo del numero de ping negativos configurados, se genera un incidente de Ping Negativo.
- El rango de tiempo configurado para el tiempo de gracia será de 1 minuto.
- La cantidad de strikes actual esta configurado en 2 para todos los aliados.
- Solo después de validar el tiempo de intermitencia, se genera el incidente de perdida o recuperación de la conectividad de acuerdo a la definición del mismo.
Importante
Si no utilizas webhooks, la evaluacion cada 3 minutos se hace sobre la ultima vez que descargaste ordenes, el tiempo de gracia para determinar si es un ping negativo es de 1 minuto
Importante
Existen tiendas que tiene horario fraccionado durante el día, por tanto, este horario se debe tener en cuenta para la generación del ping
Importante
Es impórtate aclarar que NO aplica para las tiendas que tienen horario de 24 horas
REGLAS PING
Estas son las siguientes reglas que tenemos en cuenta
PING NEGATIVO
Esta regla crea un incidente de Conectividad Perdida, este incidente esta Status: Abierto en espera de un Ping Positivo.
PING POSITIVO
En esta regla se dispara una alerta que busca el incidente de Conectividad perdida Status: Abierto para cambiarlo a Status: Cerrado.
STORE_CONNECTIVITY
El evento STORE_CONNECTIVITY
enviará el payload con el siguiente formato:
{ "external_store_id": "999", "enabled": false, "message": "The Store is not enabled to operate" }
Donde external_store_id (String) representa el id de la tienda configurada de su lado.
Donde enabled (boolean) representa con un valor binario de la tienda está disponible para operar o no.
Donde message (String) representa un mensaje informando si la tienda esta disponible o no.
ORDER_RT_TRACKING
El evento ORDER_RT_TRACKING
enviará el payload con el siguiente formato:
{ "lat": 123.3, "lng": 1234.5, "eta_in_millis": 330000, "eta_type": "PICKUP o el DELIVERY", "order_id": 1234, "store_id": 1234, "courier_id": 1234, "created_at": "10/10/2023 12:00:20" }
Donde lat (Double) representa la latitud del mensajero. Donde lng (Double) representa la longitud del mensajero. Donde eta_in_millis (Integer) representa la distancia en millas a la que se encuentra el mensajero del restaurante. Donde order_id (Integer) representa el id del pedido en el restaurante. Donde courier_id (Integer) representa el id del mensagero que es con la entrega. Donde store_id (String) representa el Identificador de la tienda en la aplicación de Rappi. Donde created_at (String) representa la fecha en la que fui creado.
Seguridad
Para segurizar los webhooks nuestra Public API cuenta con una firma que se genera usando un código de autenticación de mensajes basado en hash (HMAC) con SHA-256 (Secure Hash Algorithm 2). Cada request tiene su propia firma, la cual se enviará en un header con el nombre Rappi-Signature y tendrá el siguiente formato
t=123456,sign=d74b65c2e68c1a84a4d5843a69ef5faf1d82f28df2dd3723e8e0dad9c54abc79
Importante
Todos headers descritos en este portal son NO case-sensitive. Para más información puedes revisar el siguiente Link
Validación tu Firma
Puedes validar la firma que llega en el header siguiendo los pasos de abajo
Important
Para validar el estado de tu firma, vas a necesitar el secret
de tu webhook.
-
Extrae la marca de tiempo y las firmas del encabezado.
1.1 Separa con una coma,",". Para crear una lista.\
1.2 Separa cada elemento nuevamente con "=" para obtener una
t
y unsign
.t
: Es el timestamp de la solicitudsign
: Es la firma
-
Crea la cadena
signed_payload
concatenando:-
El timestamp
-
El carácter
.
-
El payload
Ejemplo:
123456.{ "message" : "Este es un ejemplo" }
-
-
Calcula un HMAC con la función hash SHA256. Utiliza el
secret
como clave y use la cadenasigned_payload
como mensaje para determinar la firma esperada. -
Compara la firma en el encabezado con la firma esperada.
Ahora puedes asegurarte de que la información es válida.
Note
Asegurate de tomar el payload string en el mismo formato que llega para evitar diferencias en la firma