Повідомлення «Не вдалося розпарсити відповідь» з’являється в момент, коли програма отримує дані від сервера, API чи пристрою, але не може їх коректно прочитати. Найчастіше це стосується JSON, рідше — XML чи іншого структурованого формату. Помилка не вказує на конкретну причину, тому багато хто починає шукати рішення навмання.
На практиці проблема майже завжди зводиться до кількох типових сценаріїв: відповідь приходить у неправильному форматі, містить зайві символи, обрізана або взагалі є HTML-сторінкою помилки замість очікуваного JSON. Розуміння механізму парсингу дозволяє швидко локалізувати джерело збою і усунути його без зайвих перезапусків і перевстановлень.
У статті розберемо, як саме відбувається парсинг, які причини найчастіше викликають збій у 2025–2026 роках, як діагностувати проблему покроково та що робити в різних середовищах — від власного коду до готового ПЗ на кшталт Торгсофт.
Що насправді означає помилка парсингу відповіді
Парсинг — це процес перетворення текстового рядка у структуровані дані, з якими програма може працювати. Коли сервер повертає JSON, клієнтський код викликає метод на кшталт JSON.parse() (JavaScript), json.loads() (Python) або відповідну функцію в іншій мові. Якщо рядок не відповідає синтаксису, інтерпретатор одразу кидає виняток.
Українською локалізацією цього винятку часто і стає фраза «Не вдалося розпарсити відповідь». Вона може з’являтися:
- у власному коді веб- або мобільних застосунків;
- у системах обліку (Торгсофт, 1С тощо) під час роботи з банківськими терміналами;
- у бібліотеках для роботи з REST API;
- у інструментах моніторингу та інтеграцій.
Важливо розуміти: сама помилка майже ніколи не є «поломкою» сервера. Сервер може успішно відправити дані (код 200), але клієнт не зможе їх прочитати через порушення формату. Тому спочатку перевіряють саме вміст відповіді, а не статус-код.
Найпоширеніші причини збою
На основі аналізу реальних кейсів і технічної документації можна виділити кілька груп причин, які повторюються найчастіше.
1. Невалідний JSON-синтаксис. Зайва кома в кінці масиву або об’єкта, відсутні лапки навколо ключів, некоректно екрановані спецсимволи. Особливо часто ламають парсинг подвійні лапки всередині значень, якщо їх не екранували.
2. Відповідь не є JSON взагалі. Сервер повертає HTML-сторінку помилки (наприклад, 500 Internal Server Error), plain text або XML. Клієнт намагається розпарсити тег як JSON і одразу падає.
3. Порожня або обрізана відповідь. Мережеві збої, таймаути, проблеми з проксі чи CDN можуть призвести до того, що клієнт отримує лише частину тіла відповіді. JSON.parse(“”) або незакритий об’єкт викликають саме цю помилку.
4. Неправильний Content-Type. Заголовок вказує text/html або text/plain, хоча тіло — JSON. Деякі бібліотеки (Axios, fetch) автоматично намагаються розпарсити лише тоді, коли Content-Type правильний.
5. Специфічні випадки в готовому ПЗ. У Торгсофт, наприклад, помилка «Не вдалося розпарсити відповідь JSON» довгий час виникала через подвійні лапки в назві торгової точки, яку термінал повертав у відповіді. Виправлення з’явилося лише у версії 2022.0.36.
Покрокова діагностика: що перевірити першим
Не варто одразу змінювати код. Спочатку зберіть факти.
- Подивіться сиру відповідь. У браузері відкрийте вкладку Network (DevTools), знайдіть запит і перегляньте вкладку Response. У Postman, Insomnia чи curl зробіть те саме. Якщо бачите HTML або порожній рядок — причина вже зрозуміла.
- Перевірте статус-код і заголовки. Код 200 ще не гарантує валідний JSON. Зверніть увагу на Content-Type і Content-Length.
- Скопіюйте тіло відповіді в онлайн-валідатор (jsonlint.com або подібні). Валідатор покаже точне місце синтаксичної помилки.
- Перевірте кодування. Іноді відповідь приходить у Windows-1251 або з BOM-маркером на початку, і парсер сприймає перший байт як некоректний символ.
- Відтворіть запит вручну. Якщо використовуєте бібліотеку, зробіть той самий запит через curl. Це допоможе зрозуміти, чи проблема в бібліотеці, чи в самому сервері.
З практики: у більшості випадків вже на другому-третьому кроці стає видно, що сервер віддав сторінку помилки замість JSON або що в даних є незакрита дужка.
Як виправити помилку в різних сценаріях
У власному JavaScript / TypeScript коді
Завжди обгортайте парсинг у try/catch і логуйте сирий текст:
try {,[object Object],
const data = JSON.parse(responseText);,[object Object],
} catch (e) {,[object Object],
console.error('Не вдалося розпарсити відповідь:', responseText.slice(0, 300));,[object Object],
throw e;,[object Object],
}Якщо використовуєте fetch, спочатку перевірте response.ok і Content-Type, а вже потім викликайте response.json(). Для Axios увімкніть interceptors, які ловлять помилки парсингу і показують тіло відповіді.
У Python
Аналогічно: response.json() може кинути json.JSONDecodeError. Краще спочатку взяти response.text, перевірити, і лише потім парсити. Якщо сервер іноді повертає HTML, додайте перевірку:
if 'application/json' not in response.headers.get('Content-Type', ''):,[object Object],
raise ValueError(f'Очікувався JSON, отримано: {response.text[:200]}')У системах обліку (Торгсофт та аналоги)
Якщо помилка з’являється під час роботи з банківським терміналом:
- перевірте, чи оновлена версія ПЗ (після 2022.0.36 проблема з лапками в назві торгової точки вирішена);
- перегляньте налаштування протоколу (JSON / PosApi);
- тимчасово приберіть спецсимволи з назви торгової точки і перевірте, чи зникла помилка.
У багатьох випадках достатньо оновити термінал або змінити формат відповіді на стороні банку.
Коли відповідь приходить обрізаною
Збільште таймаут, перевірте налаштування проксі та CDN, переконайтеся, що сервер не обмежує розмір відповіді. У мобільних застосунках додатково перевірте стан мережі (перемикання Wi-Fi / мобільний інтернет часто обрізає довгі відповіді).
Типові помилки розробників і як їх уникати
Найчастіша пастка — вважати, що статус 200 гарантує валідний JSON. Друга — парсити відповідь без перевірки Content-Type. Третя — ігнорувати можливість, що сервер може повернути різні структури залежно від параметрів запиту (поліморфні відповіді).
Ще одна поширена помилка — довіряти автоматичному парсингу бібліотеки і не логувати сирий текст при збої. Без сирих даних діагностика перетворюється на ворожіння.
Корисна практика 2026 року: завжди мати middleware або interceptor, який:
- логівує статус, заголовки і перші 500 символів тіла при будь-якій помилці парсингу;
- перевіряє, чи відповідь не починається з < (ознака HTML);
- дозволяє retry з експоненційною затримкою лише для мережевих помилок, а не для синтаксичних.
Профілактика та актуальні рекомендації
Щоб зменшити ймовірність появи помилки:
- на стороні сервера завжди повертайте коректний Content-Type і валідний JSON навіть у разі внутрішньої помилки (краще структурований error-об’єкт, ніж HTML);
- використовуйте схеми валідації (JSON Schema, Zod, Pydantic) як на клієнті, так і на сервері;
- у тестах спеціально перевіряйте сценарії з порожньою відповіддю, HTML-помилкою та невалідним JSON;
- для інтеграцій із сторонніми сервісами додавайте адаптери, які нормалізують відповідь перед парсингом.
У 2025–2026 роках зросла кількість випадків, коли CDN або WAF повертають власну HTML-сторінку блокування замість відповіді API. Тому перевірка Content-Type стала ще важливішою.
Коли варто звернутися до фахівця
Якщо після перевірки сирої відповіді, валідації JSON і оновлення ПЗ помилка залишається, і ви не контролюєте серверну частину — звертайтеся до підтримки сервісу або до розробника API. Особливо це стосується банківських терміналів і сторонніх інтеграцій, де формат відповіді може змінюватися без попередження.
Для власного коду достатньо досвідченого backend- або frontend-розробника, який зможе додати детальне логування і нормалізацію відповіді. У більшості випадків проблема вирішується за кілька годин після отримання сирих даних.
Помилка «Не вдалося розпарсити відповідь» рідко буває загадковою. Майже завжди вона вказує на конкретну невідповідність між очікуваним і реальним форматом даних. Достатньо один раз побачити сиру відповідь — і шлях до рішення стає очевидним.
