Guía de integración de Rappi Connect
Rappi Connect permite a los comerciantes recibir pedidos realizados por usuarios de Rappi en nuestras aplicaciones y producir esos pedidos usando las herramientas y los procesos que tienen implementados para manejar sus propios pedidos de ecommerce. Esto garantiza que la productividad del personal de recolección de los comerciantes no se vea afectada por la producción de pedidos Rappi, y que los comerciantes pueden maximizar la producción de programación de ocupación de su personal a partir de un solo grupo de pedidos.
La responsabilidad de Rappi Connect es integrar pedidos en los sistemas de los comerciantes en el momento en que crean y gestionar el intercambio la notificación de evento entre Rappi y los comerciantes a durante el ciclo de vida del pedido.
IMPORTANTE
Cada nueva característica presentada por el equipo de Rappi Connect mejora la experiencia de usuario en las tiendas integradas. Como comerciante parte de Rappi Connect, debes comprometerte a implementar estas características nuevas dentro de las 8 semanas posteriores a su presentación.
Lista de Integración
Una vez que Rappi Connect sea implementado exitosamente, se espera que logres los siguientes objetivos:
Comprender los eventos y ciclo de vida de nuestros pedidos y cómo estos eventos impactan en la experiencia del usuario en la aplicación.
Comprender cuáles de tus eventos de cumplimiento de pedidos internos deben asignarse a los nuestros.
Comprender las limitaciones de tu ERP y/o sistema de recolección que puedan impedir la implementación de procesos avanzados de excepción de pedidos (y cómo solucionarlo).
Haber desarrollado webhooks para recibir eventos relacionados con pedidos de Rappi.
Notificar a Rappi TODOS los eventos de cumplimiento de pedidos que sucedan en tu operación.
Haber implementado apropiadamente el proceso de transferencia.
El ciclo de vida del pedido
El ciclo de vida de un pedido en Rappi Connect se puede resumir en 7 eventos. La visualización completa del ciclo de vida es sumamente importante para (1) la experiencia del usuario en tiendas integradas y, operativamente, (2) monitorear y conseguir la excelencia. Se espera que los eventos de pedidos sean intercambiados entre ambas partes en tiempo real.
Rappi esperará recibir TODOS los eventos marcados con la etiqueta evento externo. Estos eventos deben ser publicados en el endpoint de Notificación de eventos de pedidos . Este endpo recibe todos los eventos externos de los comerciantes. Para esquemas específicos de eventos, consulta la especificación de esquemas para eventos externos.
ADVERTENCIA
El no actualizar regularmente los eventos de pedidos externos en Rappi, puede hacer que nuestros bots pausen temporalmente tus tiendas, lo que podría conllevar pérdidas en el GMV (Gross Merchandise Value) y frustración en los usuarios que busquen dichas tiendas en nuestras aplicaciones.
Debes esperar recibir por parte de Rappi TODOS los eventos marcados con la etiqueta internal events. Tómate un momento para revisar los esquemas de cada evento en las especificaciones de (Rappi Connect Webhooks).
- Pedido creado
internal event
El usuario realiza un pedido en alguna de nuestras aplicaciones. Rappi PUBLICARÁ cada pedido nuevo en tu webhook de ingestión de pedidos. Cuando no puedas aceptar un pedido por cualquier razón, se espera que tu respuesta se adhiera a nuestras respuestas de error de integración. Esto es extremadamente importante para garantizar la fiabilidad de la integración y permite activar flujos de recuperación internos.
En una respuesta exitosa, Rappi espera recibir el id de pedido externo de los comerciantes. Cualquier cambio en el evento (en ambas direcciones) SIEMPRE usará el
order_id(id de pedido interno). Asegúrate de tener asignados esos identificadores para publicar y consumir eventos de pedidos apropiadamente.
- Pedido integrado
external event, esquema de referencia: orderIntegratedSchema
Consumiste exitosamente el pedido en tu sistema de recolección o ERP y ahora está disponible para ser asignado a uno de nuestros recolectores.
- Liberado al recolector
external event, esquema de referencia: releasedToPickerSchema
Tu recolector empieza con la tarea de realizar la compra para uno o más pedidos. Se espera que este evento ocurra al menos 30 minutos antes de nuestra promesa de entrega al usuario. La promesa de entrega se encuentra en cada pedido nuevo enviado por Rappi a tu webhook; bajo la propiedad
delivery.delivery_timedel cuerpo de la solicitud.
- Factura creada
external event, esquema de referencia: invoiceCreatedSchema
Tu recolector completó la tarea de compra, los artículos fueron empaquetados y facturados. Este evento le dice a Rappi que el pedido está listo para ser recogido por un repartidor.
Rappi comenzará a notificar a los repartidores que hay un nuevo pedido disponible para su entrega cuando (1) el pedido haya sido facturado por el comerciante Y (2) el
delivery.departure_timese haya cumplido. Esta lógica de doble activación permite a los comerciantes programar la producción de los pedidos planificados con mucha antelación, sin arriesgar su entrega antes de lo previsto.
- Repartidor asignado
internal event
Cuando un repartidor acepta una entrega, Rappi COLOCARÁ la información del repartidor en tu webhook de información de entrega.
- Traslado de pedido
external event
Este evento se conforma por la combinación de otros dos eventos, repartidor en tienda y en camino para su entrega. Estos eventos no se notifican mediante una solicitud http sencilla como las anteriores; sino implementando el proceso de entrega de pedidos.
- Pedido entregado
internal event
Rappi notificará a los comerciantes en su webhook de pedido entregado de cada entrega exitosa a los consumidores.
Respuestas de error de integración
Las respuestas de error de integración son un subtema del evento de pedido creado. Como se menciona en la sección anterior, cuando los comerciantes no pueden aceptar un nuevo pedido, el motivo de su rechazo debe ser comunicado apropiadamente con el código de error http 4XX y el esquema específico del motivo.
Los errores de integración se organizaron en torno a ocho grupos.
| c1 | c2 | c3 |
|---|---|---|
| Range | Group | Description |
| 10-19 | Dependencias de servicio | Solo para uso interno |
| 20-29 | Interrumpciones o errores de los comerciantes | Solo para uso interno |
| 30-39 | Detalles básicos del pedido | Información básica del pedido faltante |
| 40-49 | Información del producto | Información del producto inconsistente (catálogo, existencias, precio) |
| 50-59 | Información del usuario | Información del consumidor faltante o inconsistente |
| 60-69 | Información del domicilio del usuario | Domicilio del consumidor incompleta o inconsistente |
| 70-79 | Información de entrega | Información de hora de entrega/salida faltante o inconsistente |
| 80-99 | Reservado | |
| 90-99 | Reservado | |
| 0 | Sin categorizar | El pedido es inaceptable debido a un problema sin categorizar |
La respuesta para la mayoría de los errores de integración seguirá el basicSchema, que simplemente informa el código de error identificado. A continuación, encontrarás en la siguiente tabla todos los códigos de error posibles aplicables a las validaciones de pedidos síncronos:
| c1 | c2 | c3 | c4 |
|---|---|---|---|
| Topic | Error Code | HTTP Code | Schema |
order-id-missing | 30 | 400 | basicSchema |
order-id-duplicated | 31 | 409 | error31Schema |
store-not-found | 32 | 400 | basicSchema |
total-value-inconsistent | 33 | 400 | basicSchema |
products-not-found | 40 | 400 | error40Schema |
products-stock-out | 41 | 400 | error41Schema |
products-price-difference | 42 | 400 | error42Schema |
user-first-name | 50 | 400 | basicSchema |
user-last-name | 51 | 400 | basicSchema |
user-identification | 52 | 400 | basicSchema |
user-email | 53 | 400 | basicSchema |
user-phone-number | 54 | 400 | basicSchema |
address-street-address | 60 | 400 | basicSchema |
address-number | 61 | 400 | basicSchema |
address-neighborhood | 62 | 400 | basicSchema |
address-city | 63 | 400 | basicSchema |
address-state | 64 | 400 | basicSchema |
address-zip-code | 65 | 400 | basicSchema |
delivery-time | 70 | 400 | basicSchema |
departure-time | 71 | 400 | basicSchema |
uncategorized | 0 | 400 | freeFormSchema |
Modificaciones motivadas por el cliente
Actualmente, los usuarios están impedidos para editar los pedidos realizados en las tiendas integradas con Rappi Connect; esto incluye reprogramar sus tiempos de entrega y añadir o remover productos.
Excepciones
Se debe entender a las excepciones como cualquier evento que impida que las órdenes sigan su curso regular; tal vez uno de los SKUs del pedido ya no se encuentre disponible; o el comerciante no puede facturar temporalmente los pedidos; o incluso se corta la energía en una tienda o almacén y el cumplimiento se detiene hasta que se restablece la energía.
Cualquiera que sea la razón, las excepciones deben manejarse apropiadamente; se supone que no debemos cancelar un pedido completo porque no hay un SKU disponible; ni cancelar nunca un pedido sin que el usuario sepa el motivo exacto que condujo a este resultado.
Órdenes parciales
Enviar un pedido parcial a un cliente es un resultado causado porque uno o más SKUs en el pedido que no están disponibles en el momento de la integración o durante la tarea de compra del recolector. Se espera que TODOS los comerciantes de Rappi Connect tengan la capacidad de procesar pedidos parciales. Esto previene que los comerciantes tengan que cancelar pedido entero cuando se identifica un desabastecimiento.
Cuando se reducen las unidades de producto o se elimina por completo un producto de un pedido, Rappi espera que estos eventos se publiquen en el endpoint de Notificación de eventos de pedido. Como se mencionó anteriormente, este endpoint recibe todos los eventos externos de los comerciantes. Por lo tanto, revisa los esquemas respectivos que apliquen.
Estos eventos son de suma importancia para (1) notificar a los consumidores que recibirán un pedido parcial, (2) ajustar el monto total cobrado por el pedido y (3) evitar que el SKU faltante se muestre en la aplicación.
- Eliminar unidades de producto
external event, esquema de referencia: removeProductUnitsSchema
Debes notificar este evento siempre que sea necesario para reducir la cantidad de unidades de cualquier producto en el pedido por no tener suficiente inventario a la mano para cumplir con un pedido.
- Elimina el producto
external event, esquema de referencia: removeProductSchema
Alternativamente, en el caso de no tener stock para un SKU a mano, debes enviar una notificación para este evento para eliminar ese producto por completo del pedido.
Cuando los pedidos son cancelados
Una excepción de cancelación puede ocurrir por cualquiera de las partes; un pedido puede ser cancelado por el consumidor en nuestras aplicaciones, o puede ser cancelado por los comerciantes cuando no puedan cumplir con ese pedido. Cualquiera que sea el origen de una cancelación, la otra parte debe ser notificada de inmediato.
Siempre que un consumidor cancele un pedido, Rappi PUBLICARÁ una notificación de Pedido cancelado en tu webhook de cancelación. Revisa el esquema del evento en la especificación de webhook.
Cuando los pedidos se cancelen por parte de los comerciantes, Rappi esperará no solo ser notificado, sino también conocer el motivo que condujo a esas cancelaciones. Las notificaciones deben publicarse en el endpoint de Notificación de eventos de pedidos. Revisa la siguiente tabla de motivos de cancelación y el esquema asociado con cada uno de ellos.
| c1 | c2 | c3 |
|---|---|---|
| Topic | Cancel Reason Code | Schema |
store-not-found | 32 | basicSchema |
store-closed | 321 | cancelReason321Schema |
products-not-found | 40 | cancelReason40Schema |
products-stock-out | 41 | cancelReason41Schema |
products-price-difference | 42 | cancelReason42Schema |
products-discontinued | 43 | cancelReason43Schema |
uncategorized | 0 | freeFormSchema |
PENDIENTES, NUEVAS CARACTERÍSTICAS DE PRODUCTOS PRÓXIMAMENTE...
In the future, Rappi Connect will expand to include the much-loved functionality provided by our Personal Shopper Operations. These include:
Características para consumidor
- “Chat con tu comprador personal”.
- Ofrecer artículos alternativos con diferencias significativas de precio.
- Editar pedidos (antes de que comience la recolección).
- Editar órdenes durante la recolección (mediante chat).
- Editar el horario de entrega.
- Ver el estatus de tu pedido.
- Solicitar un automóvil en lugar de bicicleta para pedidos grandes.
Características para comercio
- Ofrecer productos con opciones de ingredientes.
- Ofrecer ofertas de combinación de productos.
- Sugerir productos alternativos para las existencias agotadas.