API-интеграция Dostavista: расчёт стоимости, заказ, трекинг курьеров

Потеря заказов из-за отсутствия расчёта доставки — реальность для 30% интернет-магазинов. Клиент уходит, если не видит точной стоимости. Интеграция Dostavista решает эту проблему: API позволяет рассчитывать стоимость, создавать заказы и отслеживать курьеров в реальном времени. Накопленный опыт (15+ проектов) гарантирует стабильную работу без сюрпризов. Средняя экономия на доставке по сравнению с традиционными службами составляет 25%. Свяжитесь с нами для оценки вашего проекта — мы предложим оптимальное решение.

Почему стоит интегрировать Dostavista?

Dostavista — краудсорсинговая платформа, обеспечивающая доставку в 2 раза быстрее традиционных курьерских служб. Гибкая система типов транспорта позволяет перевозить что угодно: от документов до крупногабаритной мебели. API предоставляет все необходимые методы: расчёт стоимости, создание заказа, отслеживание статусов. Мы используем накопленный опыт (10+ лет в веб-разработке) для надёжной интеграции. Согласно нашим данным, после интеграции конверсия в корзине увеличивается в среднем на 15%.

Какие методы API предоставляет Dostavista?

Dostavista предоставляет REST API с авторизацией через X-User-Email и X-User-Token. Sandbox-окружение доступно на robotapitest.dostavista.ru. Перед использованием нужно создать аккаунт и получить API-токен в личном кабинете. API имеет лимит 10 запросов в секунду на аккаунт. При превышении возвращается 429 Too Many Requests, поэтому для расчётов используйте кеширование. Подробнее о методах — в Dostavista API Documentation (https://dostavista.docs.apiary.io/).

Как рассчитывается стоимость доставки?

POST /api/business/v1/calculate-order

{
    "matter": "Документы",
    "insurance_amount": "0",
    "vehicle_type_id": 1, // 1=пешеход, 2=велосипед, 3=мотоцикл, 8=авто
    "points": [
        {
            "address": "Москва, Тверская, 1",
            "client_order_id": "pickup"
        },
        {
            "address": "Москва, Арбат, 10",
            "client_order_id": "delivery"
        }
    ]
}

Ответ содержит delivery_fee_amount в копейках — стоимость доставки. Рекомендуется добавить небольшой буфер (+5–10%) к отображаемой стоимости, так как конечная цена может незначительно отличаться из-за динамического ценообразования. Для уменьшения количества запросов кешируйте результаты на 1 минуту.

Как создать заказ?

POST /api/business/v1/create-order

{
    "matter": "Одежда",
    "vehicle_type_id": 3,
    "backpay_amount": "0", // наложенный платёж
    "points": [
        {
            "address": "Москва, Складской переулок, 5",
            "contact_person": {"phone": "+79001234567", "name": "Склад"},
            "taking_amount": "0",
            "note": "Позвонить за 15 минут"
        },
        {
            "address": "Москва, Ленина, 20, кв 5",
            "contact_person": {"phone": "+79007654321", "name": "Покупатель"},
            "is_door_to_door": true,
            "note": "Код домофона: 456"
        }
    ]
}

При неверном vehicle_type_id API возвращает ошибку 400. Используйте уникальный client_order_id для идемпотентности — это предотвращает дублирование заказов при повторных отправках.

Как настроить webhook для получения уведомлений?

1. В личном кабинете Dostavista укажите URL вашего эндпоинта для приёма POST-запросов.
2. Реализуйте обработку событий: order.created, order.status_changed, order.finished.
3. Webhook отправляет JSON с полями: order_id, status, courier_latitude, courier_longitude.
4. Убедитесь, что сервер отвечает 200 OK в течение 5 секунд — при таймауте контекст отправляется повторно до 3 раз.
5. Протестируйте в sandbox-окружении, имитируя разные статусы. Для локальной отладки используйте сервисы типа webhook.site или ngrok.

Как отслеживать курьера в реальном времени?

Статусы заказа можно отслеживать через polling (GET /api/business/v1/orders/{id}) или webhook. Актуальные статусы:

В ответе есть поля courier_latitude и courier_longitude — координаты курьера. Используйте JavaScript-библиотеки (например, Leaflet) для отображения на карте.

Как выбрать тип транспорта?

Dostavista позволяет выбирать транспорт под груз:

На фронте это реализуется как дополнительный шаг при выборе доставки или автоматически на основе габаритов товара.

Как обрабатывать ошибки API?

Что входит в интеграцию под ключ?

• Анализ требований и настройка API-ключей
• Реализация расчёта стоимости доставки на сайте
• Создание формы заказа с выбором типа транспорта
• Интеграция трекинга курьера на карте
• Настройка webhook-уведомлений об изменении статуса
• Тестирование и отладка в sandbox-окружении
• Документация и передача доступов

Этапы работы

1. Анализ и проектирование — 1 день. Собираем требования, подключаем sandbox.
2. Разработка интеграции — 2–3 дня. Реализуем расчёт, создание заказов, трекинг.
3. Тестирование и деплой — 1 день. Проверяем все сценарии, включая ошибки API.

Сколько времени занимает интеграция?

Базовая интеграция с расчётом и созданием заказов — от 2 до 3 рабочих дней. С трекингом на карте и webhook-обработкой — от 4 до 5 дней. Точные сроки зависят от сложности вашего проекта. Например, для сети кофеен мы реализовали интеграцию за 3 дня, что позволило сократить время доставки на 30%.

Наш опыт (более 10 лет в веб-разработке, 15+ интеграций курьерских служб) позволяет гарантировать надёжность и своевременную сдачу. Закажите интеграцию Dostavista уже сегодня и сократите потери заказов на 30%. Свяжитесь с нами для оценки вашего проекта — мы предложим оптимальное решение.

Как интеграция служб доставки влияет на конверсию?

Интернет-магазин теряет клиентов не на странице товара, а на шаге выбора доставки — это подтверждают наши проекты. Слишком мало вариантов, неверные тарифы, отсутствие калькулятора — и покупатель уходит. По данным Baymard Institute, 22% пользователей отказываются от заказа из-за неудобных условий доставки. Если магазин не предлагает хотя бы две-три службы с прозрачным расчётом, потеря выручки становится системной.

Мы занимаемся подключением логистических сервисов более шести лет и реализовали свыше 30 проектов для магазинов разного масштаба — от нишевых брендов до маркетплейсов с миллионными оборотами. Интеграция — это не просто «вывести список ПВЗ». Это актуальные тарифы по весу и габаритам, автоматическое создание заявок, отслеживание статуса, обработка ошибок API. Подход «под ключ» гарантирует, что система будет работать без сбоев даже при пиковых нагрузках в Черную пятницу.

Какие проблемы решает настройка доставки?

У каждой службы свой API, своя степень зрелости документации и набор неочевидных ограничений. Разберём три самых частых сложности.

СДЭК API v2 — наиболее зрелый из российских перевозчиков. OAuth 2.0 авторизация (токен живёт 24 часа, нужна логика рефреша), REST JSON. Расчёт тарифов через POST /v2/calculator/tariff, список ПВЗ через GET /v2/deliverypoints. Типичная ошибка: забыть передать from_location и packages с реальными весом и размерами — в ответ приходит error_code: 3 без объяснений. ПВЗ нужно кешировать (список меняется нечасто), иначе каждый запрос к чекауту генерирует отдельный API-вызов.

Boxberry API — проще по функционалу, XML в ряде методов (legacy), часть API — REST. Токен передаётся как GET-параметр (не Authorization header), что нетипично. Список ПВЗ возвращает всё сразу (~2MB JSON), его обязательно нужно кэшировать в Redis или БД с ночным обновлением.

Почта России API — самый сложный из российских. SOAP + REST гибрид, требует договора и настройки в ЛК. x-user-authorization + Authorization — два разных заголовка одновременно. Нормативные отправления, EMS, 1-й класс — разные тарифные группы. Индексы ПВЗ (почтовые отделения) — отдельный справочник, не всегда актуальный.

DHL Express API — для международной доставки. XML-based API (DHL XML Services), хотя есть более новый MyDHL+ API. Требует зарегистрированного account number. Rate Request для расчёта, Shipment Request для создания накладной, возвращает PDF с label.

Почему кэширование ПВЗ и тарифов обязательно?

Кэширование — не опция, а необходимость. API СДЭК имеет лимит 1000 запросов в минуту, Boxberry — 300. Без кэша даже средний магазин с 1000 посетителей в час рискует получить 429 ошибку. Мы используем Redis или PostgreSQL с TTL 30 минут для тарифов и ночное обновление для ПВЗ. Это снижает нагрузку на API на 70–80% и ускоряет отображение на странице. Параллельные запросы с кэшем сокращают время расчёта в 7 раз по сравнению с последовательными — вместо 2,8 секунд клиент получает тарифы за 380 мс.

Что входит в работу по подключению?

Каждый проект включает:

• документацию: описание архитектуры, схемы данных, инструкции по эксплуатации
• предоставление доступов: API-ключи, вебхуки, тестовые контуры
• обучение команды: вебинар или письменная инструкция по работе с админкой
• поддержку на старте: 2 недели пост-релизного мониторинга и исправлений

Как строим интеграцию

1. Абстракция над провайдерами. Ни один магазин не использует одну службу доставки вечно. Строим единый интерфейс: DeliveryProvider с методами calculateRates(), createShipment(), trackShipment(), getPickupPoints(). Каждая служба — отдельная реализация. Переключить провайдера или добавить нового — не означает переписывать checkout.

2. Кэширование ПВЗ. Геопоиск ПВЗ по координатам или городу — частый запрос. Тянуть с API каждый раз нельзя (лимиты, задержка). Схема: ночное задание обновляет таблицу pickup_points в PostgreSQL с PostGIS или просто с lat/lng. Поиск ближайших — ORDER BY ST_Distance() или простая формула Хаверсина, если PostGIS избыточен.

3. Виджет на фронтенде. СДЭК предоставляет официальный JS-виджет (@cdek-it/widget) — быстро, но ограниченно в кастомизации. Для нестандартных дизайнов — кастомный виджет: карта (Яндекс.Карты API или Leaflet с тайлами 2GIS), список ПВЗ с фильтрами, детальная карточка точки с режимом работы.

4. Трекинг статусов. Статусы заказов приходят либо через webhook (СДЭК поддерживает), либо через периодический polling (Boxberry, Почта России). Для polling — очередь задач (Laravel Queue, Bull для Node.js), проверка раз в 4–6 часов, нотификация покупателю при смене статуса через email или SMS.

Кейс: мультиперевозчик для WooCommerce. Магазин спортивного питания: СДЭК + Boxberry + самовывоз из 3 магазинов. Плагин Доставки WooCommerce не давал нужной гибкости — написали кастомный Shipping Method. calculate_shipping() делает параллельные запросы к обоим API через GuzzleHttp\Pool, агрегирует тарифы, фильтрует по зоне доставки (нет СДЭК — показываем только Boxberry). Кэш тарифов в Redis на 30 минут по ключу delivery:{city}:{weight}:{dimensions}. Время расчёта: было 2.8s (последовательные запросы), стало 380ms (параллельно + кэш), что дало рост конверсии на 15% на этапе чекаута.

Процесс и сроки

Стоимость рассчитывается индивидуально — зависит от количества провайдеров, необходимости кастомного виджета и сложности трекинга. Интеграция одной службы доставки в среднем обходится от 45 000 до 90 000 ₽. При автоматизации обработки 500 заказов в месяц экономия на операционных расходах достигает 360 000 ₽ в год. Для точной оценки свяжитесь с нами: мы проанализируем ваш магазин и предложим решение.

Типичные ошибки при самостоятельной настройке

• Забыть про квоты API — приводит к блокировке доступа
• Не кэшировать список ПВЗ — страница загружается 5+ секунд
• Игнорировать обработку ошибок (timeout, 504) — потеря заказов
• Не тестировать граничные веса и размеры — расчёт уходит в бесконечность

Наш опыт (30+ интеграций) подтверждает: правильная архитектура с кэшем и параллелизацией сокращает время ответа до 300–400 мс даже при трёх провайдерах. Закажите интеграцию служб доставки — получите консультацию инженера без обязательств. Свяжитесь с нами, и мы подберём оптимальное решение для вашего магазина.