Configura la integración de Wolt Drive ejecutando un flujo de tres fases: verifica la disponibilidad con un endpoint de promesa o tarifa, crea la entrega y luego rastreala a través de webhooks y una URL de seguimiento generada. La mayoría de las integraciones de restaurantes y POS deberían usar endpoints venueful, ya que los lugares están preconfigurados del lado de Wolt. Tu próximo paso es simple: solicita credenciales de staging a tu contacto de Wolt y valida el flujo completo antes de que alguien te emita claves de producción.
***
TL;DR:
>
- La mayoría de los desarrolladores eligen erróneamente los endpoints incorrectos para su modo, aumentando errores y complicando el proceso de integración. - El modo venueful reduce la carga útil y los riesgos de error para restaurantes de alto volumen al utilizar datos de lugar preconfigurados, mientras que el modo venueless se adapta a puntos de recogida de bajo volumen o temporales. - El manejo de webhooks debe ser impulsado por eventos con procesamiento idempotente para evitar actualizaciones de estado perdidas y fallos en las notificaciones a los clientes. - Comenzar directamente en producción omite la validación crucial de staging, arriesgando problemas de límite de tasa y respuestas de webhook poco fiables durante la operación en vivo. - Una integración completa incluye probar todos los escenarios de entrega, manejar los límites de tasa de manera adecuada y planificar la gestión de credenciales para un lanzamiento sin problemas.
***
Tabla de Contenidos
- Qué hace Wolt Drive y quién debería integrarlo
- El proceso de integración de la API de entrega de Wolt, paso a paso
- Venueful vs Venueless: qué modo de endpoint se adapta a tu configuración
- Onboarding, autenticación y entornos: SSIO vs WIO
- Lista de verificación de implementación y trampas a evitar
- Cómo RESTOBOT integra Wolt Drive en el stack completo de tu restaurante
- Fuentes
- Preguntas Frecuentes
Qué hace Wolt Drive y quién debería integrarlo
Wolt Drive es una red de mensajería de última milla en la que las empresas se conectan para entregas ASAP o programadas, sin contratar o gestionar sus propios conductores. Un restaurante, un supermercado o un minorista envía una solicitud de entrega a través de la API de Wolt Drive, y Wolt se encarga de la asignación de mensajeros, la ruta y la notificación al cliente.
Tres grupos suelen construir esta integración:
- Sistemas POS que quieren dirigir pedidos completados directamente a un mensajero sin que el personal toque una tercera aplicación.
- Pagos de comercio electrónico que necesitan precios de entrega en vivo y ETAs en el punto de venta.
- Plataformas de middleware que orquestan la entrega a través de múltiples redes de mensajería a la vez.
La ventaja para los comerciantes es la velocidad y la reducción de costos: sin personal de entrega que gestionar, un enlace de seguimiento generado automáticamente para cada pedido y la logística de mensajería manejada completamente fuera de tu carga. Los socios de integración como los conectores de sistemas POS y pantallas de cocina también ofrecen enlaces plug-and-play bidireccionales para comerciantes que prefieren omitir el desarrollo personalizado por completo.
El proceso de integración de la API de entrega de Wolt, paso a paso
El proceso de integración de la API de entrega de Wolt se divide en tres fases distintas, y omitir el pedido o acortar cualquiera de ellas es donde la mayoría de las integraciones fallan.
- Verifica disponibilidad y precio. Llama a
/shipment-promisessi estás en modo venueful, o a/delivery-feepara solicitudes sin lugar. La respuesta devuelve un tiempo estimado de llegada y un precio de entrega, que debes mostrar al cliente antes de que confirme el pedido. - Crea la entrega. Una vez que el cliente se compromete, llama a
/deliveries(venueful) o a/delivery-order(sin lugar). La carga útil necesita detalles de recogida y entrega, valor del pedido y una bandera de tiempo: las entregas ASAP se despachan inmediatamente, mientras que las programadas tienen una ventana de entrega específica. - Rastrea y gestiona el pedido en vivo. Wolt envía cambios de estado a través de webhooks en lugar de hacer que tú consultes por actualizaciones. Espera transiciones como mensajero asignado, recogido, mensajero en ruta y entregado, junto con una URL de seguimiento que puedes entregar al cliente directamente o incrustar en un SMS.
Un detalle sorprende a casi todos los desarrolladores la primera vez: Wolt Drive es genuinamente impulsado por eventos, no por solicitud-respuesta para el estado. Si la arquitectura de tu sistema asume que consultarás un endpoint para "¿ya se entregó?", construirás lo incorrecto. Los webhooks son el mecanismo, punto. Tu oyente necesita estar listo para eso desde el primer día.
Dato rápido: todo el flujo se basa en cuatro endpoints clave que trabajan juntos, /shipment-promises, /delivery-fee, /deliveries y /delivery-order, y elegir el par incorrecto para tu modo es el error más común en las primeras etapas.
Venueful vs Venueless: ¿Qué modo de endpoint se adapta a tu configuración?
El modo venueful asume que tu ubicación de recogida ya está registrada como un lugar dentro del sistema de Wolt, por lo que la mayoría de tus solicitudes llevan menos campos y menos margen de error. La integración venueful se recomienda para la mayoría de los restaurantes porque la dirección, horarios y detalles de contacto del lugar ya están archivados. Llamas a /shipment-promises y /deliveries, y Wolt completa los vacíos a partir de sus propios registros.
El modo venueless existe para un caso más específico: un punto de recogida único, un pop-up o una ubicación de muy bajo volumen que no justifica una configuración formal de lugar. Aquí pasas todos los detalles de recogida y entrega en cada solicitud a través de /delivery-fee y /delivery-order, lo que significa más carga útil para gestionar y más superficie para errores.
- Venueful: menos campos por solicitud, datos de lugar preconfigurados, menor tasa de error a gran escala
- Venueless: se requieren detalles de dirección completos cada vez, mejor adaptado a ubicaciones de recogida dinámicas o raras
- La integración venueful reduce el tamaño de la carga útil y la superficie de error en configuraciones de POS de alto rendimiento específicamente
Si estás construyendo para una cadena, un grupo de franquicias o cualquier restaurante que espera un volumen regular de pedidos, venueful es el predeterminado práctico. Venueless tiene sentido para un camión de comida que hace tres pedidos a la semana desde una esquina diferente cada vez.
Consejo profesional: *Si no estás seguro de qué modo se adapta a tu modelo de negocio, habla con tu contacto de Wolt antes de escribir una línea de código. Cambiar de modo después del lanzamiento significa reconstruir tu estructura de carga útil y volver a probar todo el flujo.*
Incorporación, Autenticación y Entornos: SSIO vs WIO
Cada integración de Wolt Drive comienza en staging, no en producción. Eso no es una sugerencia; los tokens de comerciante de producción se emiten solo después de que tu integración pase la validación en el entorno de staging, así que presupuestar tiempo real de prueba antes de esperar claves en vivo.
La incorporación en sí se divide en dos caminos:
- SSIO (integración de auto-servicio): activas y gestionas los locales a través de tu propia interfaz, dándote control sobre el momento de implementación
- WIO (integración liderada por Wolt): Wolt integra los locales en tu nombre, lo que se adapta a los comerciantes que prefieren no construir herramientas de activación de locales en absoluto
- La autenticación generalmente se realiza con un token de comerciante o autenticación básica para solicitudes principales, aunque algunos endpoints utilizan patrones OAuth o JWT
- La mayoría de los flujos emiten un token por comerciante, así que planifica tu almacenamiento de credenciales y la lógica de rotación en torno a una única clave activa en lugar de tokens por local
Solicita credenciales de staging con anticipación. La brecha entre "mi código compila" y "mi código sobrevive a un retraso real del mensajero" solo aparece una vez que estás probando contra el entorno de staging de Wolt con un ID de local de prueba real.
Lista de Verificación de Implementación y Errores a Evitar
Revisa esta lista antes de escribir tu primera solicitud de producción:
- Confirma que tienes credenciales de staging y un ID de local de prueba válido.
- Construye un endpoint de escucha de webhook con lógica de reintento y retroceso, no un receptor simple que falle silenciosamente en una conexión caída.
- Maneja las respuestas de límite de tasa HTTP 429 de manera adecuada en lugar de golpear el endpoint de nuevo inmediatamente.
- Escribe manejo de errores para direcciones mal formadas, campos faltantes y claves de respuesta inesperadas.
- Configura la entrega de URL de seguimiento y, si es relevante, el contenido de notificación por SMS para pedidos de venueful.
- Prueba tanto los flujos de entrega ASAP como los programados, no solo el camino feliz.
- Simula retrasos de mensajeros y escenarios de recargo por pedidos pequeños antes del lanzamiento, no después de tu primera llamada de cliente enojado.
La trampa más común es comenzar el trabajo de integración directamente contra producción, omitiendo completamente la validación de staging porque "la documentación parece lo suficientemente simple". Un segundo lugar cercano es el manejo frágil de webhooks: un oyente que no puede sobrevivir a un evento duplicado o a un reintento de red eventualmente perderá un estado entregado y dejará a un cliente mirando una página de seguimiento obsoleta. Los expertos en la comunidad de desarrolladores señalan consistentemente que los manejadores de webhooks idempotentes con lógica de deduplicación son la solución, ya que los propios reintentos de Wolt pueden de otro modo activar el mismo evento dos veces en tu lado.
Para configuraciones sin local específicamente, el formato inconsistente de direcciones a través de solicitudes es un asesino silencioso. El endpoint de tarifa de entrega de Wolt a veces "adivina" una dirección ambigua en lugar de rechazarla de inmediato, lo que significa que una cadena de dirección descuidada puede dirigir silenciosamente a un mensajero al edificio equivocado en lugar de lanzar un error que realmente notarías.
Consejo Profesional: *Trata los límites de tasa como una restricción de diseño, no como un caso marginal. Si tu sistema agrupa la creación de pedidos durante la hora del almuerzo, incorpora la limitación de solicitudes ahora en lugar de descubrir las respuestas 429 en producción en tu noche más ocupada del viernes.*
Cómo RESTOBOT Integra Wolt Drive en el Stack Completo de Tu Restaurante
La documentación de API en bruto te dice cómo llamar a un endpoint. No te dice qué sucede con esa solicitud de entrega después de que tu sitio web toma el pedido, o cómo las actualizaciones de estado realmente llegan a tu personal de cocina. Esa es la brecha que una plataforma como RESTOBOT está diseñada para cerrar.
RESTOBOT genera un sitio web del restaurante y un menú de pedidos incrustado automáticamente una vez que se confirma una aplicación, y los pedidos realizados a través de ese sitio o el bot de pedidos de Telegram se sincronizan directamente en un panel de gestión. Desde allí, se puede crear una solicitud de entrega y pasarla a una red de mensajería como Wolt Drive sin que un miembro del personal tenga que volver a ingresar manualmente una dirección en una aplicación separada. Las actualizaciones de estado de Webhook fluyen de regreso a ese mismo panel, por lo que "el mensajero recogió" y "entregado" aparecen donde el restaurante ya está monitoreando, en tiempo real.
RESTOBOT no cobra ninguna comisión por los pedidos, independientemente de cómo se cumpla la entrega, ya sea entrega autogestionada o un servicio de mensajería que maneje la última milla. Para un restaurante que evalúa una plataforma frente a una construcción a medida: una integración directa te da control total sobre cada campo en la carga útil, pero también significa poseer la infraestructura de webhook, la validación de staging y el mapeo de POS tú mismo. Una ruta de plataforma intercambia parte de ese control granular por un despliegue más rápido y menos carga de ingeniería, lo que es más importante para los restaurantes sin un desarrollador dedicado en el personal.
*— ADMIN*
FAQ
¿Opera Wolt en los Estados Unidos?
La red de entrega de Wolt no está disponible en los Estados Unidos. Opera en una amplia área de mercados europeos, nórdicos y selectos internacionales, por lo que las empresas con sede en EE. UU. que buscan integración de mensajería bajo demanda deben evaluar los proveedores de entrega activos en su propio país.
¿Fue Wolt adquirida por DoorDash?
Wolt continúa operando bajo la marca Wolt en sus mercados existentes en lugar de ser incorporada a otra huella de servicio.
¿Cómo integras la API de Google Drive?
La integración de la API de Google Drive es un producto separado de Wolt Drive e involucra la configuración del proyecto de Google Cloud, credenciales de OAuth y puntos finales específicos de Drive para almacenamiento y compartición de archivos. No tiene superposición técnica con la logística de entrega de restaurantes o los puntos finales de Wolt Drive cubiertos en esta guía.
¿En qué países está disponible Wolt?
Wolt opera en docenas de países, concentrándose principalmente en Europa junto con varios mercados en el Medio Oriente y Asia. La cobertura varía según la ciudad, así que verifica la disponibilidad directamente con tu contacto de Wolt antes de construir una integración específica para el lugar.
¿Debería elegir el modo Venueful o Venueless para mi restaurante?
El modo Venueful es el predeterminado práctico para restaurantes e integraciones de POS porque los lugares están preconfigurados, lo que reduce el tamaño de la carga útil y disminuye el área de error. El modo Venueless solo tiene sentido para puntos de recogida únicos o ubicaciones de muy bajo volumen que no justifican una configuración formal del lugar.