Set up Wolt Drive integration by running a three-phase flow: check availability with a promise or fee endpoint, create the delivery, then track it through webhooks and a generated tracking URL. Most restaurant and POS integrations should use venueful endpoints, since venues are preconfigured on Wolt's side. Your next move is simple: request staging credentials from your Wolt contact and validate the full flow before anyone issues you production keys.
***
TL;DR:
>
- La plupart des développeurs choisissent par erreur les mauvais points de terminaison pour leur mode, augmentant les erreurs et compliquant le processus d'intégration. - Le mode venueful réduit la charge utile et les risques d'erreur pour les restaurants à fort volume en utilisant des données de lieu préconfigurées, tandis que le mode venueless convient aux points de ramassage à faible volume ou temporaires. - La gestion des webhooks doit être pilotée par des événements avec un traitement idempotent pour éviter les mises à jour de statut manquées et les échecs de notification client. - Commencer directement en production omet la validation de staging cruciale, risquant des problèmes de limitation de taux et des réponses de webhook peu fiables pendant l'opération en direct. - Une intégration complète comprend le test de tous les scénarios de livraison, la gestion des limites de taux avec grâce, et la planification de la gestion des identifiants pour un lancement en douceur.
***
Table of Contents
- What Wolt Drive Does and Who Should Integrate It
- The Wolt Delivery API Integration Process, Step by Step
- Venueful vs Venueless: Which Endpoint Mode Fits Your Setup
- Onboarding, Authentication, and Environments: SSIO vs WIO
- Implementation Checklist and Pitfalls to Avoid
- How RESTOBOT Ties Wolt Drive Into Your Restaurant's Full Stack
- Sources
- FAQ
What Wolt Drive Does and Who Should Integrate It
Wolt Drive est un réseau de coursiers de dernier kilomètre auquel les entreprises se connectent pour des livraisons ASAP ou programmées, sans embaucher ou gérer leurs propres chauffeurs. Un restaurant, un épicier ou un détaillant envoie une demande de livraison via l'API Wolt Drive, et Wolt s'occupe de l'attribution des coursiers, du routage et de la notification des clients.
Trois groupes construisent généralement cette intégration :
- Systèmes de point de vente qui souhaitent acheminer les commandes complètes directement à un coursier sans que le personnel touche une troisième application
- Caisse d'e-commerce qui a besoin de prix de livraison en direct et d'ETAs au point de vente
- Plateformes middleware orchestrant la livraison à travers plusieurs réseaux de coursiers à la fois
Le bénéfice pour les commerçants est la rapidité et la réduction des frais généraux : pas de personnel de livraison à gérer, un lien de suivi généré automatiquement pour chaque commande, et la logistique des coursiers entièrement prise en charge. Les partenaires d'intégration comme les connecteurs de systèmes de point de vente et d'affichage en cuisine offrent également des liens plug-and-play bidirectionnels pour les commerçants qui préfèrent éviter le développement personnalisé.
The Wolt Delivery API Integration Process, Step by Step
Le processus d'intégration de l'API de livraison Wolt se décompose en trois phases distinctes, et sauter l'ordre ou raccourcir l'une d'entre elles est là où la plupart des intégrations échouent.
- Vérifiez la disponibilité et le prix. Appelez
/shipment-promisessi vous êtes en mode venueful, ou/delivery-feepour les demandes sans lieu. La réponse renvoie un temps d'arrivée estimé et un prix de livraison, que vous devez montrer au client avant qu'il ne confirme la commande. - Créez la livraison. Une fois que le client s'engage, appelez
/deliveries(venueful) ou/delivery-order(venueless). La charge utile doit contenir les détails de ramassage et de dépôt, la valeur de la commande et un indicateur de timing : les livraisons ASAP sont expédiées immédiatement, tandis que celles programmées ont une fenêtre de dépôt spécifique. - Suivez et gérez la commande en direct. Wolt envoie les changements de statut via webhooks plutôt que de vous faire interroger pour des mises à jour. Attendez-vous à des transitions comme coursier assigné, ramassé, coursier en route et livré, accompagnées d'une URL de suivi que vous pouvez remettre directement au client ou intégrer dans un SMS.
Un détail surprend presque tous les développeurs la première fois : Wolt Drive est véritablement basé sur des événements, pas sur une requête-réponse pour le statut. Si l'architecture de votre système suppose que vous allez interroger un point de terminaison pour "est-ce que c'est livré ?", vous construirez la mauvaise chose. Les webhooks sont le mécanisme, point final, et votre écouteur doit être prêt pour cela dès le premier jour.
Fait rapide : l'ensemble du flux repose sur quatre points de terminaison principaux travaillant ensemble, /shipment-promises, /delivery-fee, /deliveries, et /delivery-order, et choisir la mauvaise paire pour votre mode est l'erreur la plus courante au début.
Venueful vs Venueless : Quel mode de point de terminaison convient à votre configuration
Le mode venueful suppose que votre lieu de ramassage est déjà enregistré comme un lieu dans le système de Wolt, donc la plupart de vos demandes comportent moins de champs et moins de marge d'erreur. L'intégration venueful est recommandée pour la plupart des restaurants car l'adresse, les heures et les coordonnées du lieu sont déjà enregistrées. Vous appelez /shipment-promises et /deliveries, et Wolt remplit les lacunes à partir de ses propres dossiers.
Le mode venueless existe pour un cas plus étroit : un point de ramassage unique, un pop-up, ou un emplacement à très faible volume qui ne justifie pas une configuration de lieu formelle. Ici, vous transmettez tous les détails de ramassage et de dépôt à chaque demande via /delivery-fee et /delivery-order, ce qui signifie plus de charge utile à gérer et plus de surface d'erreur.
- Venueful : moins de champs par demande, données de lieu préconfigurées, taux d'erreur plus bas à grande échelle
- Venueless : détails d'adresse complets requis à chaque fois, mieux adapté aux lieux de ramassage dynamiques ou rares
- L'intégration venueful réduit la taille de la charge utile et la surface d'erreur dans des configurations de POS à fort débit spécifiquement
Si vous construisez pour une chaîne, un groupe de franchises, ou tout restaurant s'attendant à un volume de commandes régulier, venueful est le choix pratique par défaut. Venueless a du sens pour un camion de nourriture faisant trois commandes par semaine depuis un coin différent à chaque fois.
Conseil pro : *Si vous n'êtes pas sûr de quel mode convient à votre modèle commercial, parlez à votre contact Wolt avant d'écrire une ligne de code. Changer de mode après le lancement signifie reconstruire votre structure de charge utile et retester l'ensemble du flux.*
Intégration, Authentification et Environnements : SSIO vs WIO
Chaque intégration Wolt Drive commence en staging, pas en production. Ce n'est pas une suggestion ; les jetons de marchand production sont délivrés uniquement après que votre intégration ait passé la validation dans l'environnement de staging, donc prévoyez un temps de test réel avant d'attendre des clés en direct.
L'intégration elle-même se divise en deux voies :
- SSIO (intégration d'auto-service) : vous activez et gérez les établissements via votre propre interface, vous donnant le contrôle sur le calendrier de déploiement
- WIO (intégration d'activation dirigée par Wolt) : Wolt active les établissements en votre nom, ce qui convient aux commerçants qui préfèrent ne pas construire d'outils d'activation des établissements
- L'authentification fonctionne généralement avec un jeton commerçant ou une authentification de base pour les requêtes principales, bien que certains points de terminaison utilisent des modèles OAuth ou JWT
- La plupart des flux émettent un jeton par commerçant, donc planifiez votre stockage de crédentiels et votre logique de rotation autour d'une seule clé active plutôt que des jetons par établissement
Demandez des crédentiels de staging tôt. L'écart entre "mon code compile" et "mon code survit à un véritable retard de coursier" ne se manifeste qu'une fois que vous testez contre l'environnement de staging de Wolt avec un véritable ID d'établissement de test.
Liste de contrôle de mise en œuvre et pièges à éviter
Passez en revue cette liste avant d'écrire votre première requête de production :
- Confirmez que vous avez des crédentiels de staging et un ID d'établissement de test valide.
- Construisez un point de terminaison d'écoute de webhook avec une logique de réessai et de retour en arrière, pas un récepteur nu qui échoue silencieusement sur une connexion perdue.
- Gérez gracieusement les réponses de limitation de taux HTTP 429 au lieu de marteler à nouveau le point de terminaison immédiatement.
- Écrivez une gestion des erreurs pour les adresses mal formées, les champs manquants et les clés de réponse inattendues.
- Configurez la livraison d'URL de suivi et, si pertinent, le contenu de notification SMS pour les commandes de venue.
- Testez à la fois les flux de livraison ASAP et programmés, pas seulement le chemin heureux.
- Simulez des retards de coursier et des scénarios de frais supplémentaires pour les petites commandes avant le lancement, pas après votre premier appel de client mécontent.
Le piège le plus courant est de commencer le travail d'intégration directement contre la production, en sautant complètement la validation de staging parce que "la documentation semble suffisamment simple." Un deuxième piège proche est la gestion fragile des webhooks : un écouteur qui ne peut pas survivre à un événement dupliqué ou à une nouvelle tentative réseau finira par manquer un statut livré et laisser un client fixant une page de suivi obsolète. Les initiés de la communauté des développeurs pointent systématiquement vers des gestionnaires de webhook idempotents avec une logique de dé-duplication comme solution, puisque les propres réessais de Wolt peuvent autrement déclencher le même événement deux fois de votre côté.
Pour les configurations sans établissement spécifiquement, un formatage d'adresse incohérent à travers les requêtes est un tueur silencieux. Le point de terminaison des frais de livraison de Wolt "devinera" parfois une adresse ambiguë plutôt que de la rejeter complètement, ce qui signifie qu'une chaîne d'adresse négligée peut discrètement diriger un coursier vers le mauvais bâtiment au lieu de générer une erreur que vous remarqueriez réellement.
Astuce Pro : *Traitez les limites de taux comme une contrainte de conception, pas comme un cas marginal. Si votre système regroupe la création de commandes pendant le rush de déjeuner, intégrez dès maintenant un throttling des requêtes plutôt que de découvrir les réponses 429 en production lors de votre vendredi soir le plus chargé.*
Comment RESTOBOT intègre Wolt Drive dans l'ensemble de votre restaurant
La documentation API brute vous indique comment appeler un point de terminaison. Elle ne vous dit pas ce qui arrive à cette demande de livraison après que votre site Web prenne la commande, ni comment les mises à jour de statut atteignent réellement votre personnel de cuisine. C'est le vide qu'une plateforme comme RESTOBOT est conçue pour combler.
RESTOBOT génère automatiquement un site web de restaurant et un menu de commande intégré une fois qu'une application est confirmée, et les commandes passées via ce site ou le bot de commande Telegram se synchronisent directement dans un tableau de bord de gestion. De là, une demande de livraison peut être créée et transmise à un réseau de coursiers comme Wolt Drive sans qu'un membre du personnel ait à ressaisir manuellement une adresse dans une application séparée. Les mises à jour de statut Webhook reviennent dans ce même tableau de bord, donc "coursier récupéré" et "livré" apparaissent là où le restaurant surveille déjà, en temps réel.
RESTOBOT ne prélève aucune commission sur les commandes, peu importe comment la livraison est effectuée, que ce soit par livraison auto-gérée ou un service de coursier gérant le dernier kilomètre. Pour un restaurant pesant la plateforme par rapport à une construction sur mesure : une intégration directe vous donne un contrôle total sur chaque champ dans la charge utile, mais cela signifie également posséder l'infrastructure Webhook, la validation de mise en scène et le mappage POS vous-même. Un itinéraire de plateforme échange une partie de ce contrôle granulaire pour un déploiement plus rapide et moins de frais d'ingénierie, ce qui est le plus important pour les restaurants sans développeur dédié dans le personnel.
*— ADMIN*
FAQ
Wolt opère-t-il aux États-Unis ?
Le réseau de livraison de Wolt n'est pas disponible aux États-Unis. Il opère dans une empreinte substantielle de marchés européens, nordiques et internationaux sélectionnés, donc les entreprises basées aux États-Unis cherchant une intégration de coursier à la demande doivent évaluer les fournisseurs de livraison actifs dans leur propre pays.
Wolt a-t-il été acquis par DoorDash ?
Wolt continue d'opérer sous la marque Wolt dans ses marchés existants plutôt que d'être intégré dans une autre empreinte de service.
Comment intégrez-vous l'API Google Drive ?
L'intégration de l'API Google Drive est un produit distinct de Wolt Drive et implique la configuration d'un projet Google Cloud, des identifiants OAuth et des points de terminaison spécifiques à Drive pour le stockage et le partage de fichiers. Il n'a aucun chevauchement technique avec la logistique de livraison de restaurant ou les points de terminaison Wolt Drive couverts dans ce guide.
Dans quels pays Wolt est-il disponible ?
Wolt opère dans des dizaines de pays, concentrés principalement en Europe ainsi que dans plusieurs marchés au Moyen-Orient et en Asie. La couverture varie selon la ville, donc vérifiez la disponibilité directement avec votre contact Wolt avant de construire une intégration spécifique à un lieu.
Dois-je choisir le mode Venueful ou Venueless pour mon restaurant ?
Le mode Venueful est le défaut pratique pour les restaurants et les intégrations POS car les lieux sont préconfigurés, ce qui réduit la taille de la charge utile et diminue la surface d'erreur. Le mode Venueless n'a de sens que pour des points de ramassage uniques ou des emplacements à très faible volume qui ne justifient pas une configuration formelle de lieu.