Інтеграція PickPoint: постамати, API, трекінг

Покупці часто кидають кошик, якщо на сайті немає зручного способу доставки. PickPoint — мережа з 4000+ постаматів (https://uk.wikipedia.org/wiki/Постамат) у 500 містах — вирішує цю проблему: клієнт забирає замовлення в будь-який час без черг. Ми, як веб-розробники, вбудовуємо цей сервіс у ваш інтернет-магазин так, щоб усе працювало без збоїв. Гарантуємо стабільну інтеграцію та зниження витрат на доставку на 15–20%. За нашими проєктами, економія на логістиці сягає 150 000 грн на рік. Наприклад, для інтернет-магазину з 500 замовленнями на місяць використання PickPoint знижує витрати на доставку на 20%, що становить 2500 грн економії щомісяця.

Як ми інтегруємо PickPoint: покроково

Інтеграція починається з аудиту поточної архітектури вашого сайту. Якщо у вас моноліт на Laravel або React-додаток з Next.js — ми підберемо оптимальний спосіб підключення. Зазвичай використовуємо REST API PickPoint (документація доступна після реєстрації в партнерському кабінеті). Для простих задач вистачає SOAP, але REST гнучкіший і легше кешується.

Ми рекомендуємо REST: JSON парситься швидше, а структура запитів інтуїтивно зрозуміла. Підключаємося до sandbox-середовища для тестів, після налагодження — до продакшену.

Чому важливо кешувати список постаматів?

Кожен запит до API постаматів повертає повний список — понад 4000 точок. Якщо викликати його при кожному завантаженні сторінки, сервер отримає надмірне навантаження, а користувач — довге завантаження карти. Ми кешуємо список в Redis або MySQL з оновленням раз на добу. Це знижує TTFB на 30–50%. Середній час завантаження карти з кешем — 0.5 секунди, без кешу — 2 секунди.

// Приклад кешування в Laravel
$postamats = Cache::remember('pickpoint_postamats', 86400, function () {
    return Http::get('https://e-solution.pickpoint.ru/api/postamatlist')->json();
});

Типові помилки при інтеграції та їх вирішення:

• Невірний заголовок авторизації: Переконайтеся, що в запитах передається заголовок Authorization: Bearer {token}. Інакше API повертає 401.
• Ігнорування лімітів запитів: PickPoint обмежує кількість запитів за хвилину. Налаштуйте чергу запитів із затримкою.
• Відсутність обробки помилок: Завжди перевіряйте response.status і виводьте зрозуміле повідомлення користувачу.

Інтеграція PickPoint: етапи та строки

1. Аудит — аналізуємо поточну архітектуру та точки інтеграції.
2. Підключення до API — налаштовуємо доступ до PickPoint, валідуємо дані.
3. Кешування — реалізуємо кеш списку постаматів для швидкого завантаження.
4. Фронтенд — виводимо карту з постаматами, фільтруємо за габаритами.
5. Вебхуки — налаштовуємо прийом статусів відправлень.
6. Тестування — перевіряємо в sandbox-середовищі, виправляємо помилки.
7. Деплой — переносимо в продакшен, навчаємо менеджерів.

Типові помилки при інтеграції PickPoint

Помилки при розрахунку вартості. Якщо невірно передати габарити посилки, PickPoint може повернути некоректну ціну або відмовити в прийомі. Ми валідуємо дані перед відправкою і підказуємо користувачу допустимі розміри.

Проблеми з трекінгом замовлення PickPoint. Статуси відправлень приходять через вебхуки PickPoint. Якщо URL вебхука недоступний, статуси втрачаються. Ми налаштовуємо чергу повторних відправок та алерти для адміністратора.

Невірний вибір постамату. Клієнт може вибрати постамат, який не підходить за габаритами замовлення. Ми рахуємо сумісність на льоту і ховаємо непідходящі точки зі списку.

Як вибрати постамат для клієнта?

На стороні фронтенду ми виводимо карту з постаматами, отриманими з кешу. Клієнт клікає на точку — підвантажуються її параметри: адреса, час роботи, вільні комірки. Ми перевіряємо, чи поміщається замовлення (за MaxWidth/MaxHeight/MaxDepth з API). Якщо ні — попереджаємо користувача і пропонуємо інший постамат.

// Приклад фільтрації за габаритами
const suitable = postamats.filter(p => 
  order.width <= p.MaxWidth && 
  order.depth <= p.MaxDepth && 
  order.height <= p.MaxHeight
);

Що входить в роботу?

• Документація по інтеграції: опис усіх API-методів, приклади запитів і відповідей.
• Код модуля для вашої CMS або фреймворку (Laravel, WordPress, 1C-Бітрікс, React).
• Тестування на sandbox-середовищі PickPoint.
• Навчання ваших менеджерів: як керувати відправленнями, друкувати етикетки.
• Налаштування друку етикеток PickPoint.
• Підтримка протягом 2 тижнів після запуску.

За час нашої практики ми інтегрували PickPoint у 20+ проєктах — від інтернет-магазинів одягу до сервісів доставки їжі. Жодне замовлення не загубилося через збій інтеграції. Наш досвід показує, що використання PickPoint зменшує кількість покинутих кошиків у 2 рази порівняно з відсутністю зручної доставки. Зв'яжіться з нами для безкоштовної оцінки проєкту — інженер проаналізує ваш сайт і запропонує рішення. Пишіть нам у будь-який зручний месенджер.

Скільки часу займає інтеграція?

Базове підключення (вибір постамату на карті, створення відправлення PickPoint, трекінг замовлення PickPoint) — 3–4 робочих дні. Якщо потрібна інтеграція з обліковою системою (1С, CRM) або нестандартна логіка — від 7 до 10 днів. Вартість розраховується індивідуально після аналізу вашого проєкту. Економія часу порівняно з самостійною розробкою — до 40%. Пропонуємо інтеграцію під ключ: ви отримуєте готовий модуль з уже налаштованим кешем, вебхуками та друком етикеток.

Для точної оцінки надішліть технічне завдання або посилання на сайт — ми проаналізуємо і запропонуємо рішення протягом дня. Замовте інтеграцію служби доставки PickPoint сьогодні — і ваші клієнти забудуть про проблеми з доставкою.

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

Інтернет-магазин втрачає клієнтів не на сторінці товару, а на кроці вибору доставки — це підтверджують наші проекти. Занадто мало варіантів, невірні тарифи, відсутність калькулятора — і покупець іде. За даними 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% на етапі чекауту.

Процес та терміни

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

Типові помилки при самостійному налаштуванні

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

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