Перейти до основного вмісту

Історія змін

Зміни в API та в цій документації, свіжі згори.

2026-10-22​

API

  • SMS, яке не вдалося передати оператору до кінця терміну життя — sms_lifetime, а якщо його не задано, через 72 години після запланованого часу відправки, — тепер отримує фінальний статус EXPIRED. Він приходить так само, як звіт оператора: у вебхук і звіт про доставку. Раніше таке повідомлення могло лишатися в статусі QUEUED без фінального статусу.
  • Повідомлення в напрямок, маршрут до якого недоступний, одразу відхиляється з Operator not supported — статус NO ROUTE, status_detail channel.no_route — і не списується. Раніше воно могло бути прийняте й так і не відправлене.
  • Звіти в кабінеті клієнта показують і повідомлення, які так і не були відправлені: їх видно за часом створення.
  • Таке SMS не списується: коли воно отримує EXPIRED, так і не потрапивши до оператора, його ціна повертається на баланс — окремим рядком в історії балансу. Повідомлення, яке дійшло до оператора й не було доставлене, оплачується, як і раніше.
  • Вебхук також приносить фінальні статуси, які не надходять зі звіту оператора: EXPIRED для повідомлення WhatsApp, про яке постачальник так і не прозвітував, і всі фінальні статуси Telegram.

2026-10-20​

API

  • Нове поле status_detail — чому повідомлення має такий статус, дворівневим кодом: recipient.no_viber_user означає, що повідомлення Viber не доставлено, бо на номері немає Viber. Повертається в статусі JSON і вебхуку, статусі XML, статусі HTTP і звіті про доставку. Є, лише коли причину відомо; сам статус не змінюється. Усі коди — в Уточненнях статусу. Перший рівень називає, де причина: recipient, sender, template, content, policy, channel.

2026-09-27​

API

  • У WhatsApp — увесь вміст повідомлення. Шаблон може нести в шапці картинку, відео, документ, локацію або текст зі значенням, кнопку-посилання зі значенням, купон для копіювання, а шаблон підтвердження надсилає одноразовий код. Протягом 24 годин після останнього повідомлення абонента вільне повідомлення може нести файл із підписом, локацію, картку з кнопкою та прев’ю посилання. Див. Відправка повідомлення WhatsApp.
  • Новий метод template/whatsapp/list: погоджені шаблони ваших відправників і те, що потрібно кожному під час відправки, — див. Список шаблонів WhatsApp.
  • Вебхук несе replies і для WhatsApp — текст, натиснуту кнопку, файл і локацію. Сповіщення whatsapp/inbound теж несе файл і локацію.

Документація

  • Відправка OTP коду (WhatsApp) — переписана: код надсилається шаблоном підтвердження. Твердження, що type: whatsapp відхиляється, більше не вірне — тип приймається, як і whatsapp+sms.
  • Контракт OpenAPI описує whatsapp, whatsapp+sms і template/whatsapp/list.

2026-09-09​

Документація

  • У JSON API з'явився машиночитаний контракт: openapi.yaml та openapi.json, посилання — на сторінці Структура запиту. Файл імпортується в Postman, Insomnia або генератор клієнта. Він описує конверт запиту, усі двадцять задокументованих операцій за data[].type, формат відповіді та вебхук зі статусом доставки. Адреса сервера у файлі — та, що діє для цього сайту.

2026-09-02​

API

  • Вебхуки про статус повторюються: до трьох спроб із паузами 10 і 60 секунд. Повтор буває лише при обриві зв'язку, таймауті, 5xx або 429; успіхом вважається строго 200. Обробник має бути ідемпотентним. Див. Вебхук, Verify (OTP) і Callback-сповіщення.
  • MCP-конектор: інструмент send_whatsapp надсилає запит типом pipeline. Поле signature стало обов'язковим, необов'язкова пара sms_signature + sms_message додає досилку SMS. Виклик зі старим набором аргументів (phone, message, confirm) більше не проходить схему інструмента — див. Інструменти конектора.

Документація

  • Callback-сповіщення — новий розділ Звіт про доставку на URL. Звіт був описаний лише у варіанті на e-mail, хоча шлюз надсилає його на адресу сповіщень по кожному повідомленню акаунта, яким би API воно не було надіслане. Твердження, що JSON вебхук приходить замість цих сповіщень, було хибним: надсилаються обидва.
  • Відправка OTP коду (WhatsApp) — сторінку переписано. type: whatsapp не є типом повідомлення і відхиляється з помилкою Invalid message type; WhatsApp — етап запиту pipeline.
  • У звіті про доставку на URL і на e-mail зсув часового поясу йде без двокрапки (+0300), формат був описаний неправильно.

2026-08-25​

API

  • У payload вебхука з’явилося поле success: true лише якщо повідомлення доставлено (DELIVERED, READ, REPLIED, PARTIALLY DELIVERED), інакше false. Див. Вебхук.
  • Якщо в асинхронному пакеті немає id жодного повідомлення, надсилається один вебхук з request_id, а не пропускається сповіщення.

2026-08-24​

API

  • Сповіщення про відхилене повідомлення тепер має ту саму форму, що й статус доставки: плоский об'єкт зі status: REJECTED і причиною в error. Поле success і вкладений масив data прибрані — один payload, один парсер. Див. Вебхук.
  • Відхилений запит тепер породжує по одному сповіщенню на кожне повідомлення з hook, кожне зі своїм id. Раніше надсилалося одне сповіщення на адресу, і про решту повідомлень пачки клієнт не дізнавався.
  • Сповіщення Verify (OTP) приведено до тієї ж форми і тепер теж містить status і updated.

2026-08-21​

Документація

  • Нова сторінка Callback-сповіщення — вхідне SMS на виділений номер, відповіді Viber 2 Way і звіт про доставку на e-mail. Жодне з цих сповіщень раніше не було описане.
  • Вебхук — додані поля request_id, reply і duration; id та msg_id — рядки, а не числа; додані правила доставки (одна спроба, без повторів, таймаути 5 секунд) і приклад відхиленого повідомлення.
  • Verify (OTP) — описано вебхук, який повідомляє про відхилений запит.
  • У прикладах запитів на сторінках JSON API з'явилися готові до запуску сніпети на cURL, PHP, Python і Node.js.
  • Команди receive, delete і price у HTTP API помилково були описані як send.
  • Wap-Push більше не описаний у документації.