Wolt Drive Integratie: RESTOBOT Ontwikkelaars Checklist voor Webhooks

Inhoudsopgave

• Wat Wolt Drive Doet en Wie Het Zou Moeten Integreren
• Het Wolt Leverings-API Integratieproces, Stap voor Stap
• Venueful vs Venueless: Welke Eindpuntmodus Past Bij Jouw Setup
• Onboarding, Authenticatie en Omgevingen: SSIO vs WIO
• Implementatie Checklist en Valkuilen om te Vermijden
• Hoe RESTOBOT Wolt Drive Verbindt Met de Volledige Stack van Jouw Restaurant
• Bronnen
• FAQ

Wat Wolt Drive Doet en Wie Het Zou Moeten Integreren

Wolt Drive is een koeriersnetwerk voor de laatste mijl dat bedrijven gebruiken voor ASAP- of geplande leveringen, zonder hun eigen chauffeurs in te huren of te beheren. Een restaurant, supermarkt of detailhandelaar stuurt een leveringsverzoek via de Wolt Drive API, en Wolt regelt de toewijzing van de koerier, de routing en de klantmelding.

Drie groepen bouwen doorgaans deze integratie:

• POS-systemen die voltooide bestellingen rechtstreeks naar een koerier willen sturen zonder dat personeel een derde app aanraakt
• E-commerce afrekeningen die live leveringsprijzen en ETA's nodig hebben op het verkooppunt
• Middleware-platforms die leveringen over meerdere koeriersnetwerken tegelijk coördineren

De voordelen voor handelaren zijn snelheid en verminderde overhead: geen leveringspersoneel om te beheren, een trackinglink die automatisch voor elke bestelling wordt gegenereerd, en de logistiek van de koerier volledig uit handen genomen. Integratiepartners zoals POS- en keukenweergavesysteemverbindingen bieden ook tweeweg plug-and-play links voor handelaren die liever helemaal geen maatwerkontwikkeling willen doen.

Het Wolt Leverings-API Integratieproces, Stap voor Stap

Het Wolt leverings-API integratieproces is opgedeeld in drie afzonderlijke fasen, en het overslaan van de bestelling of het inkorten van een van hen is waar de meeste integraties falen.

1. Controleer beschikbaarheid en prijs. Bel /shipment-promises als je in venueful-modus bent, of /delivery-fee voor venueless verzoeken. De respons geeft een geschatte aankomsttijd en een bezorgprijs terug, die je aan de klant moet tonen voordat ze de bestelling bevestigen.
2. Creëer de levering. Zodra de klant zich commit, bel je /deliveries (venueful) of /delivery-order (venueless). De payload heeft ophaal- en afleverdetails, orderwaarde en een timing-vlag nodig: ASAP-leveringen worden onmiddellijk verzonden, terwijl geplande leveringen een specifiek aflevervenster hebben.
3. Volg en beheer de live bestelling. Wolt duwt statuswijzigingen via webhooks in plaats van dat je updates moet opvragen. Verwacht overgangen zoals koerier toegewezen, opgehaald, koerier onderweg en afgeleverd, naast een tracking-URL die je direct aan de klant kunt geven of in een SMS kunt opnemen.

Een detail verrast bijna elke ontwikkelaar de eerste keer: Wolt Drive is echt event-driven, niet request-response voor status. Als je systeemarchitectuur ervan uitgaat dat je een eindpunt polst voor "is het al afgeleverd," bouw je het verkeerde. Webhooks zijn het mechanisme, punt uit, en je listener moet daar vanaf dag één klaar voor zijn.

Snelle feit: de hele flow rust op vier kern-eindpunten die samenwerken, /shipment-promises, /delivery-fee, /deliveries, en /delivery-order, en het kiezen van het verkeerde paar voor jouw modus is de meest voorkomende vroege fout.

Venueful vs Venueless: Welke Eindpuntmodus Past Bij Jouw Setup

Venueful-modus gaat ervan uit dat je ophaallocatie al geregistreerd is als een locatie in het systeem van Wolt, dus de meeste van je verzoeken bevatten minder velden en minder ruimte voor fouten. Venueful-integratie wordt aanbevolen voor de meeste restaurants omdat het adres, de openingstijden en contactgegevens van de locatie al bekend zijn. Je belt /shipment-promises en /deliveries, en Wolt vult de gaten aan de hand van zijn eigen gegevens.

Venueless-modus bestaat voor een nauwere casus: een eenmalig ophaalpunt, een pop-up, of een locatie met een zeer laag volume die geen formele locatie-instelling rechtvaardigt. Hier geef je volledige ophaal- en afleverdetails door bij elk verzoek via /delivery-fee en /delivery-order, wat betekent dat er meer payload te beheren is en meer kans op fouten.

• Venueful: minder velden per verzoek, vooraf geconfigureerde locatiegegevens, lagere foutpercentage op schaal
• Venueless: volledige adresgegevens vereist elke keer, beter geschikt voor dynamische of zeldzame ophaallocaties
• Venueful-integratie vermindert de payloadgrootte en het foutoppervlak in specifieke high-throughput POS-opstellingen

Als je bouwt voor een keten, een franchisegroep, of een restaurant dat regelmatig ordervolume verwacht, is venueful de praktische standaard. Venueless is logisch voor een foodtruck die drie bestellingen per week doet vanuit een andere hoek elke keer.

Pro Tip: *Als je niet zeker weet welke modus bij jouw bedrijfsmodel past, praat dan met je Wolt-contact voordat je een regel code schrijft. Wisselen van modus na de lancering betekent dat je je payloadstructuur opnieuw moet opbouwen en de hele flow opnieuw moet testen.*

Onboarding, Authenticatie en Omgevingen: SSIO vs WIO

Elke Wolt Drive-integratie begint in staging, niet in productie. Dat is geen suggestie; productiehandels-token worden alleen uitgegeven nadat je integratie de validatie in de staging-omgeving heeft doorstaan, dus budgetteer echte testtijd voordat je live sleutels verwacht.

Onboarding zelf splitst zich in twee paden:

• SSIO (self-service integratie onboarding): je activeert en beheert locaties via je eigen interface, waardoor je controle hebt over de uitroltijd
• WIO (Wolt-geleide integratie onboarding): Wolt onboardt locaties namens jou, wat past bij handelaren die liever geen activatietools voor locaties bouwen
• Authenticatie loopt doorgaans op een handelaarstoken of basisauthenticatie voor kernverzoeken, hoewel sommige eindpunten OAuth of JWT-patronen gebruiken
• De meeste flows geven één token per handelaar uit, dus plan je opslag en rotatielogica voor inloggegevens rond een enkele actieve sleutel in plaats van per-locatie tokens

Vraag staging-inloggegevens vroeg aan. De kloof tussen "mijn code compileert" en "mijn code overleeft een echte koeriersvertraging" komt pas naar voren wanneer je test tegen Wolt's staging-omgeving met een echt testlocatie-ID.

Implementatie Checklist en Valkuilen om te Vermijden

Loop deze lijst door voordat je je eerste productieaanroep schrijft:

1. Bevestig dat je staging-inloggegevens en een geldig testlocatie-ID hebt.
2. Bouw een webhook-luisterendpoint met retry- en backoff-logica, niet een kale ontvanger die stilzwijgend faalt bij een verbroken verbinding.
3. Behandel HTTP 429 rate-limit reacties op een nette manier in plaats van het eindpunt onmiddellijk opnieuw te belasten.
4. Schrijf foutafhandeling voor onjuiste adressen, ontbrekende velden en onverwachte respons-sleutels.
5. Configureer de levering van tracking-URL's en, indien relevant, SMS-notificatie-inhoud voor locatiebestellingen.
6. Test zowel ASAP- als geplande leveringsflows, niet alleen het gelukkige pad.
7. Simuleer koeriersvertragingen en kleine bestellingskosten-scenario's vóór de lancering, niet na je eerste boze klantoproep.

De meest voorkomende valkuil is het direct starten van integratiewerk tegen productie, waarbij staging-validatie volledig wordt overgeslagen omdat "de documentatie er eenvoudig genoeg uitziet." Een close tweede is kwetsbare webhook-afhandeling: een luisteraar die geen dubbele gebeurtenis of een netwerkretry kan overleven, zal uiteindelijk een geleverde status missen en een klant met een verouderde trackingpagina achterlaten. Insiders in de ontwikkelaarsgemeenschap wijzen consequent op idempotente webhook-handlers met deduplicatielogica als de oplossing, aangezien Wolt's eigen retries anders dezelfde gebeurtenis twee keer aan jouw kant kunnen triggeren.

Voor locaties zonder opstellingen is inconsistente adresopmaak tussen verzoeken een stille moordenaar. Wolt's bezorgkosten-eindpunt zal soms een ambigu adres "het beste raden" in plaats van het outright te weigeren, wat betekent dat een slordige adresstring stilletjes een koerier naar het verkeerde gebouw kan leiden in plaats van een fout te genereren die je daadwerkelijk zou opmerken.

Pro Tip: *Behandel rate limits als een ontwerpeis, niet als een randgeval. Als je systeem bestellingen bundelt tijdens de lunchdrukte, bouw dan nu verzoek-throttling in in plaats van de 429-responses in productie op je drukste vrijdagavond te ontdekken.*

Hoe RESTOBOT Wolt Drive in de Volledige Stack van Je Restaurant Verbindt

Ruwe API-documentatie vertelt je hoe je een eindpunt aanroept. Het vertelt je niet wat er met dat bezorgverzoek gebeurt nadat je website de bestelling heeft genomen, of hoe statusupdates daadwerkelijk je keukenpersoneel bereiken. Dat is de kloof die een platform zoals RESTOBOT probeert te dichten.

RESTOBOT genereert automatisch een website voor restaurants en een ingebed bestelmenu zodra een aanvraag is bevestigd, en bestellingen die via die site of de Telegram-bestelbot worden geplaatst, synchroniseren direct naar een managementdashboard. Van daaruit kan een bezorgverzoek worden aangemaakt en doorgestuurd naar een koeriersnetwerk zoals Wolt Drive, zonder dat een medewerker handmatig een adres in een aparte app hoeft in te voeren. Webhook-statusupdates stromen terug naar datzelfde dashboard, zodat "koerier opgehaald" en "geleverd" verschijnen waar het restaurant al in real-time naar kijkt.

RESTOBOT rekent geen commissie op bestellingen, ongeacht hoe de bezorging wordt uitgevoerd, of dat nu zelfbeheerste bezorging of een koeriersdienst die de laatste mijl afhandelt is. Voor een restaurant dat een platform afweegt tegen een op maat gemaakte oplossing: een directe integratie geeft je volledige controle over elk veld in de payload, maar dat betekent ook dat je zelf verantwoordelijk bent voor de webhook-infrastructuur, staging-validatie en POS-mapping. Een platformroute ruilt een deel van die gedetailleerde controle in voor snellere uitrol en minder engineering overhead, wat vooral belangrijk is voor restaurants zonder een toegewijde ontwikkelaar in dienst.

*— ADMIN*

FAQ

Operateert Wolt in de Verenigde Staten?

Het bezorgnetwerk van Wolt is niet beschikbaar in de Verenigde Staten. Het opereert in een aanzienlijk gebied van Europese, Noordse en selecte internationale markten, dus Amerikaanse bedrijven die op zoek zijn naar on-demand koeriersintegratie moeten bezorgproviders evalueren die actief zijn in hun eigen land.

Is Wolt overgenomen door DoorDash?

Wolt blijft opereren onder het Wolt-merk in zijn bestaande markten in plaats van te worden samengevoegd met een andere service.

Hoe integreer je de Google Drive API?

De integratie van de Google Drive API is een apart product van Wolt Drive en omvat de opzet van een Google Cloud-project, OAuth-gegevens en Drive-specifieke eindpunten voor bestandsopslag en -deling. Het heeft geen technische overlap met restaurantbezorglogistiek of de Wolt Drive-eindpunten die in deze gids worden behandeld.

In welke landen is Wolt beschikbaar?

Wolt opereert in tientallen landen, voornamelijk geconcentreerd in Europa, samen met verschillende markten in het Midden-Oosten en Azië. De dekking varieert per stad, dus controleer de beschikbaarheid rechtstreeks met je Wolt-contact voordat je een locatie-specifieke integratie bouwt.

Moet ik Venueful of Venueless-modus kiezen voor mijn restaurant?

Venueful-modus is de praktische standaard voor restaurants en POS-integraties omdat locaties vooraf zijn geconfigureerd, wat de payloadgrootte verkleint en het foutoppervlak vermindert. Venueless-modus is alleen logisch voor eenmalige ophaalpunten of zeer laag-volume locaties die geen formele locatieconfiguratie rechtvaardigen.

Aanbevolen

• Hoe je Wolt- en Bolt-commissies voor je restaurant kunt verlagen — eigen bezorging zonder tussenpersonen
• Telegram-bot voor restaurants: hoe te verbinden en je eerste klanten te krijgen
• Bezorgmanagementsoftware voor restaurants in 2026