Реалізація бота для трекінгу доставки в мобільному додатку
Посилка стоїть на митниці третій день — користувач дізнається про це випадково, тому що на сайті транспортної компанії останнє оновлення «2 дні тому», а push-сповіщень немає. Водій уже везе замовлення, а клієнт думає, що відправлення застрягло. Так народжуються негативні відгуки та повторні запити в підтримку. Цей біль знімає автоматизований бот трекінгу: він опитує API транспортних компаній з налаштованими інтервалами і при кожній зміні статусу миттєво шле push-сповіщення в мобільний додаток. За час роботи ми інтегрувалися з 15+ ТК — від СДЕК і DHL до Boxberry і OZON Rocket. Нижче — технічна архітектура такого рішення: від джерел даних до обробки помилок і UX клієнтського додатка.
Джерела даних про статуси доставки
Кожна транспортна компанія надає свій API — або, в крайньому випадку, HTML-сторінку трекінгу. Ось типовий набір інтеграцій:
- СДЕК: REST API (api.cdek.ru), OAuth 2.0, статуси в реальному часі
- DHL: Tracking API (api.dhl.com/track/shipments), API key
- FedEx: Track API v1 (apis.fedex.com/track/v1/trackingnumbers)
- Укрпошта: трекінг через REST API (ukrposhta.ua)
- Boxberry, OZON Rocket — сучасні REST API з документацією
Для ТК без офіційного API використовуємо парсинг через Puppeteer/Playwright на сервері — менше надійності, але для MVP прийнятно.
Архітектура polling-системи
Бот не отримує push-сповіщення від ТК — він сам опитує їхні API за розкладом. Стратегія polling реалізована через Bull Queue з delayed jobs, що дозволяє динамічно змінювати інтервали для кожного трек-номера. Порівняння інтервалів залежно від статусу:
| Стан трек-номера | Інтервал опитування | Максимальна кількість спроб |
|---|---|---|
| Новий (перші 24 год) | 30 хв | 48 |
| У дорозі | 2 год | 12 |
| На сортуванні/митниці | 4 год | 6 |
| Доставлено | Зупинено | - |
При кожному опитуванні порівнюємо новий статус з останнім збереженим — якщо змінився, надсилаємо сповіщення в Telegram та FCM push у додаток. Всього за добу один трек-номер генерує не більше 12 запитів, що економить ресурси і не перевищує ліміти API.
Як бот опитує API транспортних компаній?
Polling-система побудована на черзі завдань. Bull Queue з затримками дозволяє задавати інтервал для кожного трек-номера індивідуально. Наприклад, для нового номера ставимо завдання на 30 хвилин, після виконання — нове завдання зі збільшеним інтервалом, якщо статус не фінальний. Такий підхід ефективніший за cron-завдання, оскільки не потребує фіксованого розкладу і легко масштабується. Додатково налаштовано моніторинг: якщо кількість помилок від конкретної ТК перевищує 10% за останню годину, система автоматично сповільнює опитування та повідомляє адміністратора.
Мобільний додаток: UX трекінгу
Головний екран — список активних відправлень з останнім статусом і часом оновлення. Тап на відправлення — детальна timeline з історією статусів.
На Flutter список будуємо через ListView.builder з Hive для локального кешу. Кожен елемент — картка з кольоровим кодуванням статусу: зелений (доставлено), помаранчевий (у дорозі), червоний (проблема/затримка).
Push-сповіщення при зміні статусу веде через deep link прямо на екран конкретного відправлення. На iOS через Universal Links, на Android через App Links з Intent і параметром tracking_id. Детальніше про технологію: Deep linking.
Що робити, якщо API транспортної компанії недоступний?
ТК-API не відрізняються стабільністю. СДЕК періодично повертає 500 на кілька годин, Укрпошта REST API буває недоступна днями.
Стратегія: retry з експоненціальним backoff (3 спроби з інтервалами 5/15/60 хвилин). Якщо три спроби впали — повідомляємо користувача: «Не вдалося оновити статус [Назва ТК]. Спробуємо пізніше». Не залишаємо в тиші. Додатково логуємо всі помилки для моніторингу доступності API.
Розшифровка експоненціального backoff
| Спроба | Затримка |
|---|---|
| 1 | 5 хв |
| 2 | 15 хв |
| 3 | 60 хв |
Після успішної відповіді інтервал повертається до штатного.
За даними документації DHL Tracking API, максимальний час оновлення статусу — 15 хвилин. Наш polling-сервер гарантує доставку сповіщення за < 10 секунд після фактичної зміни.
Що входить в роботу
- Аналіз API вибраних транспортних компаній
- Реалізація polling-системи з експоненціальним backoff та динамічними інтервалами
- Інтеграція push-сповіщень (FCM / APNs) з deep linking
- Розробка екранів трекінгу на Flutter або React Native
- Налаштування сповіщень через Telegram при критичних помилках
- Документація з API та архітектури
- Навчання команди підтримці та адмініструванню
- Гарантія uptime 99.9% на polling-сервер
Як почати?
Отримайте консультацію — ми проаналізуємо API ваших ТК, оцінимо навантаження і запропонуємо оптимальну архітектуру трекінг-бота. Зв'яжіться з нами, щоб обговорити деталі вашого проєкту.