Інтеграція Wolt Drive: контрольний список розробника RESTOBOT для вебхуків

Зміст

• Що таке Wolt Drive і хто повинен його інтегрувати
• Процес інтеграції Wolt Delivery API, крок за кроком
• Venueful проти Venueless: який режим кінцевої точки підходить для вашої налаштування
• Онбординг, автентифікація та середовища: SSIO проти WIO
• Контрольний список реалізації та підводні камені, яких слід уникати
• Як RESTOBOT інтегрує Wolt Drive у повний стек вашого ресторану
• Джерела
• Питання та відповіді

Що таке Wolt Drive і хто повинен його інтегрувати

Wolt Drive — це мережа кур'єрів для останньої милі, в яку бізнеси підключаються для термінових або запланованих доставок, не наймаючи та не керуючи власними водіями. Ресторан, продуктовий магазин або роздрібний продавець надсилає запит на доставку через Wolt Drive API, а Wolt займається призначенням кур'єра, маршрутизацією та сповіщенням клієнтів.

Три групи зазвичай створюють цю інтеграцію:

• POS-системи, які хочуть направляти завершені замовлення безпосередньо до кур'єра, не залучаючи персонал до третього додатку
• Електронна комерція, яка потребує актуальних цін на доставку та ETAs в точці продажу
• Проміжні платформи, які координують доставку через кілька мереж кур'єрів одночасно

Вигода для торговців полягає в швидкості та зниженні накладних витрат: немає персоналу для доставки, автоматично генерується посилання для відстеження для кожного замовлення, а логістика кур'єра повністю знята з ваших плечей. Партнери з інтеграції, такі як з'єднувачі POS та системи відображення на кухні, також пропонують двосторонні посилання plug-and-play для торговців, які хотіли б зовсім уникнути індивідуальної розробки.

Процес інтеграції Wolt Delivery API, крок за кроком

Процес інтеграції Wolt Delivery API ділиться на три чіткі фази, і пропуск замовлення або скорочення будь-якої з них — це те, де більшість інтеграцій зазнає невдачі.

1. Перевірте наявність і ціну. Використовуйте /shipment-promises, якщо ви в режимі venueful, або /delivery-fee для запитів без місця. Відповідь повертає оцінений час прибуття та ціну доставки, які ви повинні показати клієнту перед підтвердженням замовлення.
2. Створіть доставку. Як тільки клієнт підтвердить, викликайте /deliveries (venueful) або /delivery-order (venueless). Вантаж має містити деталі про підбір та доставку, вартість замовлення та прапорець часу: доставки ASAP відправляються негайно, тоді як заплановані мають конкретне вікно для доставки.
3. Слідкуйте та керуйте живим замовленням. Wolt передає зміни статусу через webhooks, а не змушує вас опитувати оновлення. Очікуйте переходи, такі як призначення кур'єра, забрано, кур'єр у дорозі та доставлено, разом з URL для відстеження, який ви можете передати клієнту безпосередньо або вбудувати в SMS.

Одна деталь здивує майже кожного розробника вперше: Wolt Drive дійсно працює на основі подій, а не запит-відповідь для статусу. Якщо ваша архітектура системи передбачає, що ви будете опитувати кінцеву точку на предмет "чи доставлено вже", ви створите неправильну річ. Webhooks є механізмом, крапка, і ваш слухач має бути готовий до цього з першого дня.

Швидкий факт: весь процес базується на чотирьох основних кінцевих точках, які працюють разом: /shipment-promises, /delivery-fee, /deliveries та /delivery-order, і вибір неправильної пари для вашого режиму є найпоширенішою ранньою помилкою.

Venueful проти Venueless: Який режим кінцевої точки підходить вашій налаштуванні

Режим venueful передбачає, що ваше місце підбору вже зареєстроване як місце в системі Wolt, тому більшість ваших запитів містять менше полів і менше можливостей для помилок. Інтеграція venueful рекомендується для більшості ресторанів, оскільки адреса, години роботи та контактні дані місця вже є в наявності. Ви викликаєте /shipment-promises та /deliveries, а Wolt заповнює прогалини з власних записів.

Режим venueless існує для більш вузького випадку: одноразова точка підбору, поп-ап або дуже низький обсяг, який не виправдовує формальну налаштування місця. Тут ви передаєте повні деталі підбору та доставки з кожним запитом через /delivery-fee та /delivery-order, що означає більше вантажу для управління та більше можливостей для помилок.

• Venueful: менше полів на запит, попередньо налаштовані дані місця, нижчий рівень помилок у масштабах
• Venueless: повні деталі адреси потрібні кожного разу, краще підходить для динамічних або рідкісних місць підбору
• Інтеграція venueful зменшує розмір вантажу та площу для помилок у налаштуваннях POS з високою пропускною здатністю

Якщо ви створюєте для мережі, франшизної групи або будь-якого ресторану, який очікує регулярний обсяг замовлень, venueful є практичним стандартом. Venueless має сенс для фуд-трака, який виконує три замовлення на тиждень з різного кута щоразу.

Порада професіонала: *Якщо ви не впевнені, який режим підходить вашій бізнес-моделі, поговоріть з вашим контактом у Wolt перед тим, як написати рядок коду. Перемикання режимів після запуску означає перебудову вашої структури вантажу та повторне тестування всього процесу.*

Вступ, автентифікація та середовища: SSIO проти WIO

Кожна інтеграція Wolt Drive починається в тестовому середовищі, а не в продуктивному. Це не пропозиція; токени торговців для продуктивного середовища видаються лише після того, як ваша інтеграція пройде валідацію в тестовому середовищі, тому заплануйте реальний час для тестування перед тим, як очікувати живі ключі.

Сам процес введення ділиться на два шляхи:

• SSIO (інтеграція самообслуговування): ви активуєте та керуєте закладами через свій інтерфейс, що дає вам контроль над часом впровадження
• WIO (інтеграція під керівництвом Wolt): Wolt активує заклади від вашого імені, що підходить торговцям, які не хочуть зовсім створювати інструменти активації закладів
• Аутентифікація зазвичай працює на основі токена торговця або базової аутентифікації для основних запитів, хоча деякі кінцеві точки використовують OAuth або JWT патерни
• Більшість потоків видають один токен на торговця, тому сплануйте зберігання облікових даних та логіку ротації навколо одного активного ключа, а не токенів на кожен заклад

Запитуйте облікові дані для тестування на ранньому етапі. Різниця між "мій код компілюється" і "мій код витримує затримку кур'єра" проявляється лише тоді, коли ви тестуєте проти тестового середовища Wolt з реальним ID закладу.

Контрольний список впровадження та пастки, яких слід уникати

Пройдіть цей список перед тим, як написати свій перший виробничий запит:

1. Підтвердіть, що у вас є облікові дані для тестування та дійсний ID тестового закладу.
2. Створіть кінцеву точку для прослуховування вебхуків з логікою повторних спроб та затримки, а не простий приймач, який тихо зазнає невдачі при втраті з'єднання.
3. Обробляйте відповіді HTTP 429 про обмеження швидкості коректно, а не намагаючись знову звертатися до кінцевої точки відразу.
4. Напишіть обробку помилок для неправильно сформованих адрес, відсутніх полів та несподіваних ключів відповіді.
5. Налаштуйте доставку URL для відстеження та, якщо це доречно, вміст SMS-сповіщень для замовлень з закладів.
6. Тестуйте як термінову, так і заплановану доставку, а не лише щасливий шлях.
7. Симулюйте затримки кур'єра та сценарії надбавки за малі замовлення перед запуском, а не після першого дзвінка від розгніваного клієнта.

Найпоширеніша пастка - це початок роботи з інтеграцією безпосередньо проти виробництва, повністю пропускаючи валідацію тестування, оскільки "документація виглядає досить просто". Друге місце займає крихка обробка вебхуків: прослуховувач, який не може витримати дублікат події або повторну спробу мережі, врешті-решт пропустить доставлений статус і залишить клієнта, що дивиться на застарілу сторінку відстеження. Інсайдери в розробницькій спільноті постійно вказують на ідемпотентні обробники вебхуків з логікою де-дуплікації як на вирішення, оскільки повторні спроби Wolt в іншому випадку можуть спровокувати ту ж подію двічі з вашого боку.

Для налаштувань без закладів, несумісний формат адреси в запитах є тихим вбивцею. Кінцева точка плати за доставку Wolt іноді "найкраще вгадує" неоднозначну адресу, а не відхиляє її зовсім, що означає, що неохайний рядок адреси може тихо направити кур'єра до неправильної будівлі, замість того, щоб викинути помилку, яку ви насправді помітите.

Порада: *Ставтеся до обмежень швидкості як до конструктивного обмеження, а не до крайнього випадку. Якщо ваша система групує створення замовлень під час обіду, вбудуйте обмеження запитів зараз, а не виявляйте відповіді 429 у виробництві у ваш найзавантаженіший п'ятничний вечір.*

Як RESTOBOT інтегрує Wolt Drive у повний стек вашого ресторану

Сира документація API розповідає, як викликати кінцеву точку. Вона не розповідає, що відбувається з цим запитом на доставку після того, як ваш вебсайт приймає замовлення, або як оновлення статусу насправді досягають вашого кухонного персоналу. Це та прогалина, яку платформа, така як RESTOBOT, створена для закриття.

RESTOBOT автоматично генерує вебсайт ресторану та вбудоване меню замовлень після підтвердження заявки, а замовлення, зроблені через цей сайт або бот замовлень у Telegram, синхронізуються безпосередньо в панелі управління. Звідти можна створити запит на доставку та передати його мережі кур'єрів, як-от Wolt Drive, без необхідності повторного введення адреси співробітником у окремому додатку. Оновлення статусу Webhook повертаються в ту ж панель управління, тому "кур'єр забрав" і "доставлено" з'являються там, де ресторан вже спостерігає, в реальному часі.

RESTOBOT не стягує комісію з замовлень, незалежно від того, як здійснюється доставка, чи це самостійна доставка, чи кур'єрська служба, що обробляє останню милю. Для ресторану, який порівнює платформу з індивідуальною розробкою: пряма інтеграція дає вам повний контроль над кожним полем у навантаженні, але це також означає, що вам потрібно самостійно володіти інфраструктурою webhook, перевіркою на етапі підготовки та картуванням POS. Платформний маршрут обмінює частину цього детального контролю на швидший запуск і менші витрати на інженерію, що має найбільше значення для ресторанів без спеціально виділеного розробника в штаті.

*— АДМІН*

Часті запитання

Чи працює Wolt у Сполучених Штатах?

Мережа доставки Wolt недоступна у Сполучених Штатах. Вона працює на значній території Європи, Північної Європи та вибраних міжнародних ринках, тому бізнесам у США, які шукають інтеграцію з кур'єрами на вимогу, потрібно оцінити постачальників доставки, які активні у їхній країні.

Чи була Wolt придбана DoorDash?

Wolt продовжує працювати під брендом Wolt на своїх існуючих ринках, а не бути інтегрованою в іншу службу.

Як інтегрувати Google Drive API?

Інтеграція Google Drive API є окремим продуктом від Wolt Drive і передбачає налаштування проекту Google Cloud, облікові дані OAuth та специфічні кінцеві точки Drive для зберігання та обміну файлами. Вона не має технічної перекриття з логістикою доставки ресторану або кінцевими точками Wolt Drive, описаними в цьому посібнику.

В яких країнах доступний Wolt?

Wolt працює в десятках країн, зосереджуючись переважно в Європі, а також у кількох ринках на Близькому Сході та в Азії. Покриття варіюється в залежності від міста, тому перевірте доступність безпосередньо у вашого контакту Wolt перед створенням інтеграції для конкретного закладу.

Чи слід вибрати режим Venueful або Venueless для мого ресторану?

Режим Venueful є практичним стандартом для ресторанів та інтеграцій POS, оскільки заклади попередньо налаштовані, що зменшує розмір навантаження та знижує ймовірність помилок. Режим Venueless має сенс лише для одноразових пунктів видачі або дуже малих об'єктів, які не виправдовують формального налаштування закладу.

Рекомендоване

• Як зменшити комісії Wolt і Bolt для вашого ресторану — власна доставка без посередників
• Бот Telegram для ресторанів: як підключити та отримати перших клієнтів
• Програмне забезпечення для управління доставкою для ресторанів у 2026 році