# Provider Postman > Розбір API платіжного провайдера за документацією (лінк та/або файл будь-якого формату) і генерація Postman-прикладів: локальний опис методів + нова версійна папка (v1/v2/v3…) у колекції провайдера + environment. Генерує також Postman-тести (позитивні й негативні) для кожного запиту. Покриває стандартну оплату в усіх комбінаціях SMS/DMS × 3DS провайдера / без 3DS / власний MPI (external 3DS), рекурентні платежі (токен провайдера і MIT за scheme_id / network transaction id), статус/деталі транзакції, capture, refund, void, Apple Pay / Google Pay (токен провайдера і розшифровані дані). Використовуй, коли користувач дає лінк на документацію провайдера і просить «зробити запити в Postman», «описати методи провайдера», «оновити/створити v2 (v3…) у Postman», а також на /provider-postman <лінк або файл>. - Skill: `tychynavova/provider-postman` (Agent Skill, multi-file: 5 files) - Install (CLI): `npx skillmds@latest add tychynavova/provider-postman` - Raw SKILL.md: https://api.skillmd.com/api/skills/tychynavova/provider-postman/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Integrations & APIs - Author: TychynaVova (https://skillmd.com/u/tychynavova) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/tychynavova/provider-postman --- # Provider → методи → Postman Аргументи: лінк на документацію провайдера та/або шлях до файлу (PDF, OpenAPI/Swagger YAML/JSON, Postman collection, DOCX, HTML, MD…). Якщо нічого не передано — спитай. **Джерело правди — тільки документація провайдера** (лінк/файл) і реальні відповіді провайдера. Не покладайся на локальні репозиторії: на іншому ПК їх може не бути. Якщо користувач сам попросить звірити з кодом — це окремий крок, не частина цього процесу. Мова всіх описів — українська. Назви полів, ендпоінтів, заголовків — як у документації. ## 0. Підготовка 1. `POSTMAN_API_KEY` — зі змінної середовища або `./.env`. Немає → попроси ключ у користувача (Postman → Settings → API Keys) і збережи в `.env` як `POSTMAN_API_KEY=…`. У ключа обмежений термін дії: 401 від Postman = ключ протух, попроси новий. 2. Хелпер: `python3 <директорія цього skill-а>/postman_builder.py` (команди `workspaces`, `find`, `tree`, `build`, `sync`, `update`, `tests`, `verify`; опис — у docstring). Статистика сесії — `session_stats.py` там само. Директорія skill-а — це «Base directory» з заголовка, з яким завантажився skill. Формат специфікації — `spec.example.json` там само. 3. Робоча директорія для опису: `./provider-docs//` (від поточної директорії сесії). Проміжні файли (завантажені специфікації, чернетки spec) — у scratchpad. ## 1. Збір методів з документації 1. Відкрий лінк (WebFetch). Якщо сторінка рендериться JS-ом або контент неповний — через Chrome (skill `claude-in-chrome`) або пошукай машиночитну специфікацію: `openapi.json/yaml`, `swagger`, «Download OpenAPI», «Run in Postman», GitHub-репозиторій SDK/spec провайдера. Специфікація OpenAPI / Postman collection від провайдера — найкраще джерело, бери її, якщо є. 2. Файл від користувача — прочитай повністю (PDF — сторінками), це рівноцінне джерело до лінку. 3. Пройди навігацію документації (API reference, Guides) і знайди методи за категоріями: | Категорія | Що шукати | |---|---| | Автентифікація | тип (Bearer, Basic, HMAC-підпис, OAuth token), заголовки, як отримати токен, sandbox vs prod base URL | | Режими SMS / DMS | див. «SMS / DMS» нижче — обов'язково для кожного методу оплати | | 3DS / без 3DS / external MPI | див. «3DS» нижче — обов'язково для кожного методу оплати | | Стандартна оплата | create payment / authorize / sale / charge, 3DS (redirect, challenge, callback), confirm | | Рекурентні | збереження картки/токена (tokenize, customer, payment method, mandate), MIT / off-session на токені провайдера | | MIT за scheme_id | див. «MIT за scheme_id» нижче — обов'язкова перевірка | | Статус / деталі | get payment / transaction / order, пошук за order id | | Capture (DMS) | повний і частковий, множинні capture, capture більшої суми (якщо дозволено) | | Void / Cancel (DMS) | скасування авторизації до capture, причини; чи можна void після capture (зазвичай ні) | | Refund | повний і частковий, множинні refund-и, статус refund-у; для SMS — єдиний спосіб повернення | | Apple Pay | (a) токен провайдера / зашифрований payment token → провайдер розшифровує; (b) **розшифровані дані** (DPAN / network token + cryptogram + ECI) — merchant decrypt, див. «Гаманці: розшифровані дані» | | Google Pay | (a) токен провайдера / encrypted paymentData; (b) **розшифровані дані** (CRYPTOGRAM_3DS і PAN_ONLY) — див. «Гаманці: розшифровані дані» | | Вебхуки / IPN | формат нотифікацій, підпис — **лише описати**, запити в Postman не створювати | | Тестові дані | тестові картки (успіх, decline, 3DS), тестові токени гаманців, test helpers | **SMS / DMS.** SMS (Single Message) — авторизація і списання одним запитом (sale / purchase / auto capture), повернення лише через refund. DMS (Dual Message) — авторизація з блокуванням коштів (hold), потім окремий capture або void; після capture — тільки refund. Для провайдера з'ясуй: - як обирається режим: окремі ендпоінти (`/sale` vs `/authorize` + `/capture`), параметр у запиті (`capture_method=automatic|manual`, `intent=CAPTURE|AUTHORIZE`, `auto_capture`, `type=SALE|AUTH`…) чи налаштування акаунта/MID (тоді в запиті режиму не видно — так і запиши); - термін життя авторизації, що відбувається після нього (auto-void / auto-capture); - частковий / множинний capture, void після часткового capture; - які статуси повертаються в кожному режимі (напр. `requires_capture` / `authorized` vs `succeeded` / `captured`); - чи підтримується кожен режим для recurring, Apple Pay, Google Pay (буває, що гаманці — лише SMS). Якщо документація не згадує DMS — запиши «DMS у документації не знайдено», не вигадуй capture/void. **3DS.** Три режими автентифікації власника картки — з'ясуй кожен: - **3DS провайдера** (провайдер — 3DS Server): як увімкнути/примусити (`three_ds: required`, `request_three_d_secure=any`…); обов'язкові дані для 3DS2 — browser info (accept header, user agent, language, color depth, screen, time zone, java/js enabled, IP), `return_url`/`notification_url`, дані власника (email, billing address, phone); чи є 3DS Method (device fingerprint, `methodURL`, `threeDSMethodData`) і як повідомити його результат; як виглядає challenge (redirect URL, `acsURL` + `creq`, для 3DS1 — `PaReq`/`MD`), яким запитом завершується (complete / confirm / authorize after 3DS) або що фінальний статус приходить лише вебхуком; що повертається (ECI, CAVV, `dsTransID`, `transStatus` Y/A/N/U/C/R, liability shift); frictionless vs challenge; підтримка 3DS1 (якщо ще є) і 3DS2; тестові картки для frictionless, challenge, failed, attempted. - **Без 3DS**: як вимкнути (`three_ds: skip`, налаштування MID…), чи дозволено провайдером; винятки SCA (low value, TRA, MIT, whitelisting — поля `exemption`/`sca_exemption`), що буде при soft decline (коди `1A` / `65`, «authentication required») і як повторити з 3DS. - **External MPI** (3DS пройдено власним MPI мерчанта): чи підтримується; поля з результатами автентифікації — `authentication_value`/CAVV/AAV (формат, кодування), `eci`, `ds_transaction_id` (3DS2) / `xid` (3DS1), `version`, `trans_status`, `acs_transaction_id`, `exemption`, `challenge_indicator`; які з них обов'язкові для кожної версії та платіжної системи. Для гаманців: Apple Pay / Google Pay CRYPTOGRAM_3DS самі несуть cryptogram + ECI (3DS не потрібен); Google Pay PAN_ONLY зазвичай вимагає 3DS — перевір. Для recurring: MIT зазвичай без 3DS; перший CIT для збереження картки — з 3DS; перевір, чи провайдер приймає 3DS / external MPI дані на рекурентних. Не підтримується режим — запиши «не підтримується / не знайдено» із джерелом. **MIT за scheme_id (обов'язкова перевірка).** Мерчант сам зберігає картку (PAN у власному vault, network token, DPAN/MPAN гаманця) і ID транзакції платіжної системи з першого CIT (scheme id / network transaction id: Visa Transaction ID, Mastercard Trace ID / Financial Network Code…) і проводить наступні MIT через провайдера — у т.ч. якщо перший платіж ішов через іншого провайдера. З'ясуй: - **звідки брати scheme id**: поле у відповіді на initial / у статусі / у вебхуку (`network_transaction_id`, `scheme_transaction_id`, `scheme_reference`, `trace_id`, `transaction_identifier`…), для якого флоу воно повертається (CIT з 3DS, без 3DS, гаманці); - **як передати в MIT**: поле з попереднім scheme id (`previous_network_transaction_id`, `mit_exemption[network_transaction_id]`, `original_transaction_id`, `scheme_reference`…) і stored-credential індикатори: ініціатор (`merchant`), тип MIT (`recurring` / `unscheduled` / `installment`, `stored_credential_transaction_type`), використання (`first` / `subsequent`), `off_session` / `recurring_indicator`; чи потрібен прапорець на першому CIT (`first` / `setup`); - **джерело картки в MIT**: PAN (зазвичай потребує PCI / дозволу на raw card data), network token (+ cryptogram чи без), DPAN/MPAN Apple Pay, Google Pay; чи потрібен CVV/3DS (зазвичай ні); - SMS / DMS для MIT, обмеження мереж, коди відмов (напр. «transaction not permitted»); - статус: **публічно** / **закрита функція** (джерело) / **не підтримується** / **не знайдено** — ті самі джерела й порядок пошуку, що для розшифрованих даних гаманців (включно зі старими папками колекції та питанням до користувача). **Гаманці: розшифровані дані (обов'язкова перевірка).** Мерчант сам розшифровує токен Apple Pay / Google Pay і передає провайдеру дані картки-токена. Шукай наполегливо — такі можливості часто закриті (вмикаються для акаунта) і не описані в публічному API reference: 1. Публічна документація та специфікація: пошук за `network_token`, `cryptogram`, `eci`, `electronic_commerce_indicator`, `dpan`, `tokenization_method`, `decrypted`, `merchant decryption`, `payment_data`, `onlinePaymentCryptogram`, `eciIndicator`, `authMethod`, `CRYPTOGRAM_3DS`, `PAN_ONLY`, `network token`, `wallet`/`apple_pay`/`google_pay` у параметрах запиту оплати. 2. Непублічні / суміжні джерела: support-статті і changelog провайдера, офіційні SDK на GitHub (назви полів у моделях запитів), сторінки «network tokens», «card-on-file / migration», «raw card data», **наявні папки колекції провайдера в Postman** (`tree`) і файли від користувача. 3. Якщо в публічних джерелах немає — **спитай користувача**, чи є приватна документація / приклад запиту від провайдера (з акаунт-менеджером часто домовляються окремо). Для кожного гаманця зафіксуй статус: **публічно** / **закрита функція** (знайдено лише в непублічних джерелах — вказати джерело) / **не підтримується** (з посиланням) / **не знайдено**. Опиши маппінг полів розшифрованого токена на параметри провайдера: - Apple Pay (`paymentData` після розшифрування): `applicationPrimaryAccountNumber` → номер токена; `applicationExpirationDate` (YYMMDD) → місяць/рік; `paymentData.onlinePaymentCryptogram` → cryptogram; `paymentData.eciIndicator` → ECI (часто доповнити нулем до 2 символів); `paymentDataType` (`3DSecure` / `EMV`); `deviceManufacturerIdentifier`; тип токена (DPAN / MPAN) для recurring. - Google Pay (`paymentMethodDetails`): `pan`, `expirationMonth`, `expirationYear`, `authMethod` (`CRYPTOGRAM_3DS` → `cryptogram` + `eciIndicator`, як network token; `PAN_ONLY` → звичайна картка, часто з 3DS провайдера), `messageExpiration`. Для кожного підтримуваного варіанта також: SMS/DMS, recurring (MIT на network token / DPAN / MPAN). Для кожного методу збери: HTTP-метод і шлях, лінк на сторінку методу, обов'язкові та опційні параметри (тип, формат, обмеження), заголовки (idempotency, версія API, підпис), формат суми (мінорні одиниці / десяткові, zero-decimal валюти), приклад запиту і відповіді, статуси, коди помилок. 4. Чогось немає в документації (наприклад, void або decrypted Apple Pay) — так і запиши «у документації не знайдено» з переліком місць, де шукав. Не вигадуй ендпоінти й поля. ## 2. Локальний опис методів Файл `./provider-docs//methods.md` (якщо вже є — онови, дата в шапці): ```markdown # — API методи Джерело: <лінк(и)> / <файл>. Зібрано: . ## Автентифікація та загальне Base URL (sandbox / prod), auth, обов'язкові заголовки, idempotency, формат суми, версія API. ## Режими SMS / DMS | | SMS | DMS | |---|---|---| | Як увімкнути | … | … | | Статус після оплати | … | … | | Capture / Void | — | повний/частковий/множинний; термін авторизації | | Повернення | refund | void до capture, refund після | | Card / Recurring / Apple Pay / Google Pay | ✅/❌ | ✅/❌ | ## 3DS | | 3DS провайдера | Без 3DS | External MPI | |---|---|---|---| | Як увімкнути | … | … | … | | Обов'язкові поля | browser info, return_url… | … | CAVV, ECI, dsTransID, version… | | Потік / завершення | frictionless / challenge → … | — | — | | Статуси | … | … | … | | Card / Recurring / Apple Pay / Google Pay | ✅/❌ | ✅/❌ | ✅/❌ | | Тестові картки | frictionless / challenge / fail | … | — | ## <Категорія> ### <Назва методу> - **Запит:** `POST /path` - **Документація:** <лінк на метод> - **Призначення:** 1–2 речення. - **Режим:** SMS / DMS / обидва (яким параметром); 3DS провайдера / без 3DS / external MPI (якими полями). - **Параметри:** список `name` (тип, required/optional) — опис/допустимі значення. - **Приклад запиту / відповіді:** короткі блоки коду. - **Статуси / помилки:** ключові значення. - **Примітки:** 3DS, обмеження, відмінності sandbox. ## MIT за scheme_id | | Статус | Джерело | Поле scheme id у відповіді CIT | Поля в MIT | SMS / DMS | |---|---|---|---|---|---| | Card (PAN) | … | … | … | … | … | | Network token | … | … | … | … | … | | Apple Pay DPAN / MPAN | … | … | … | … | … | | Google Pay | … | … | … | … | … | Stored-credential індикатори (first / subsequent, recurring / unscheduled / installment): … ## Гаманці: розшифровані дані | | Статус (публічно / закрита функція / не підтримується / не знайдено) | Джерело | Поля | SMS / DMS | Recurring | |---|---|---|---|---|---| | Apple Pay decrypted | … | … | … | … | … | | Google Pay CRYPTOGRAM_3DS | … | … | … | … | … | | Google Pay PAN_ONLY | … | … | … | … | … | Маппінг полів розшифрованого токена → параметри запиту: … ## Не знайдено в документації - … ``` Поруч збережи завантажені специфікації (openapi.json тощо), якщо вони були. ## 3. Колекція та версійна папка в Postman 1. `postman_builder.py find ` — знайди колекцію провайдера та його оточення. Робочий простір — той, де лежить колекція. Для нової колекції: `workspaces` → покажи список і спитай користувача, куди створювати (якщо він не назвав сам). Обраний workspace запам'ятай для наступних разів. 2. `tree ` — подивись наявні папки та оточення, щоб зрозуміти, як провайдера тестували раніше (корисно для тестових даних), але **не копіюй** їх структуру наосліп. 3. Версія: - колекції немає → створюється колекція `` з папкою `v1`; - є тільки папки без версії → `v2`; - є `vN` → `v(N+1)`. `build` рахує це сам (`"version": null`). Наявні папки не чіпай. 4. Структура всередині `vN` (порожні категорії пропускай, нумерація підпапок наскрізна): 1. `Card — Initial` 2. `Card — Recurring` — підпапки `Provider token` і `Scheme ID (MIT)` 3. `Status / Details` 4. `Capture / Void / Refund` 5. `Apple Pay` (`Provider token` та `Decrypted data` — окремими запитами/флоу) 6. `Google Pay` (так само) **Всі варіанти — обов'язково.** Для кожного методу оплати (Card initial, recurring, Apple Pay, Google Pay) створи **кожну комбінацію, яку підтримує провайдер**: `{3DS провайдера | Non-3DS | External MPI} × {SMS | DMS}`, для гаманців ще `× {Provider token | Decrypted data}`. Нічого не скорочуй і не замінюй приміткою «відрізняється одним параметром» — кожен варіант має бути готовим до запуску запитом. - Всередині методу — підпапка на режим 3DS (`3DS (provider)`, `Non-3DS`, `External MPI`; для гаманців спершу `Provider token` / `Decrypted data`, далі режими 3DS, якщо вони там доречні). У підпапці — запити флоу; запит оплати двома варіантами: `1. Create Payment (3DS, SMS)` і `1. Create Payment (3DS, DMS)` (однаковий номер — це альтернативи одного кроку). - `3DS (provider)`: після оплати — усі кроки, які є в провайдера: 3DS Method, Complete 3DS / Confirm, отримання статусу. Browser info — у тілі запиту літералами (реалістичні значення). - Опис кожного варіанта: чим відрізняється (параметр/ендпоінт), очікуваний статус, яку тестову картку взято і який сценарій вона дає (frictionless / challenge / decline). - **`Scheme ID (MIT)` створюється завжди** (у `Card — Recurring`, а для гаманців — у `Apple Pay` / `Google Pay` → `Recurring — Scheme ID`): - флоу: `1. Initial CIT (…)` зі stored-credential прапорцем `first`, що зберігає scheme id у змінну оточення (`saves`, напр. `scheme_id`), і `2. MIT by scheme_id (…)`, що його використовує; якщо провайдер повертає scheme id лише в статусі чи вебхуку — між ними `Get Payment`; - варіанти: кожне підтримуване джерело картки (PAN / network token / DPAN) × кожен тип MIT (`recurring`, `unscheduled`, `installment` — ті, що підтримує провайдер) × {SMS, DMS}; окремий запит «MIT за зовнішнім scheme_id» (scheme id від іншого провайдера — літерал-приклад); - статус «закрита функція» → суфікс `[Private]`, в описі джерело параметрів і що функцію треба ввімкнути (PCI / raw card data тощо); «не знайдено» → як для гаманців (питання користувачу, інакше папка з описом без запитів). - **Гаманці — `Decrypted data` створюється завжди** для Apple Pay і Google Pay: - статус «публічно» → усі комбінації: Apple Pay decrypted × {SMS, DMS}; Google Pay `CRYPTOGRAM_3DS` × {SMS, DMS} і `PAN_ONLY` × {3DS провайдера, Non-3DS, External MPI (якщо можна)} × {SMS, DMS}; плюс recurring на збереженому токені, якщо підтримується; - статус «закрита функція» → ті самі запити, у назві суфікс `[Private]`, в описі: звідки взято параметри, що функцію треба ввімкнути у провайдера, і маппінг полів із розшифрованого токена; - «не знайдено» → після відповіді користувача: є приклад/доки → як «закрита функція»; немає → папка без запитів з описом, де шукали і що відсутнє; - дані в тілі — реалістичний формат (DPAN 16 цифр, cryptogram base64 28 символів, ECI `05`/`07`), явно позначені в описі як приклад: з тестовими ключами провайдера вони пройдуть лише якщо провайдер це дозволяє в sandbox. - Непідтримувані комбінації не створюй — перелічи їх в описі підпапки методу («DMS для Google Pay не підтримується — <лінк>»). - Режим задається тільки налаштуванням акаунта/MID → один запит і примітка про це. - У `Capture / Void / Refund`: capture і void позначені `(DMS)`, в описі — void лише до capture, після нього — refund; частковий capture / refund — окремими запитами, якщо підтримуються. Скрипт підтримує вкладені папки довільної глибини (`folders` всередині папки в spec). Запити в підпапці нумеруй у порядку виконання флоу (`1. …`, `2. …`). Допоміжні запити, яких немає в реальній інтеграції (test helpers, емуляція фронту), познач `[Test helper]` / `[Frontend emulation]` у назві. ## 4. Генерація запитів і environment Склади spec (формат — `spec.example.json`) у scratchpad і запусти `postman_builder.py build --dry`, потім без `--dry`. Після створення впиши в spec `collection_uid` і `version` — далі правки тільки через `update ` (оновлює на місці за назвами). **Доповнення наявної версії** (користувач просить «доопиши / додай відсутнє» у вже створеній `vN`): 1. Візьми spec цієї версії (`./provider-docs//*_spec.json`); якщо його немає — `tree` і відтвори структуру в spec (назви папок і запитів — точно як у Postman). 2. Звір вміст `vN` з поточними правилами skill-а (усі комбінації 3DS × SMS/DMS, `Scheme ID (MIT)`, `Decrypted data`, `[Private]`-статуси, описи з джерелами) і допиши в spec відсутнє; зміни в описах наявних запитів — окремим частковим spec (лише змінені запити). 3. `sync --dry` → `sync ` — створює відсутні папки/запити, оновлює описи папок, додає в оточення нові змінні (значення наявних не чіпає); далі `update <частковий spec>` для змінених запитів. 4. Онови `methods.md` (нові таблиці/статуси, кількість запитів) і `verify`. Наявні запити, які користувач міг правити вручну, не перезаписуй без потреби. Правила: - **Документація в кожному запиті:** поле `docs` (лінк на конкретний метод) — хелпер додає `📖 Документація: <лінк>` в опис запиту; для підпапок — `docs` папки; для версійної папки — `docs_url`. - **Опис запиту:** що робить, звідки беруться значення, обов'язкові/опційні поля, допустимі значення. Опційні поля, які зазвичай не шлють, — додай вимкненими (4-й елемент `false`). - **Auth** — `auth` верхнього рівня spec: хелпер ставить його на версійну папку **і явно в кожен запит** з відповідним Auth Type (Bearer / Basic / API Key…), бо запит, створений через API без auth, Postman показує як «No Auth» і не успадковує від папки. Запит з іншою авторизацією — власне поле `auth` у spec (напр. `{"type": "noauth"}` для публічного ендпоінта). Підпис запиту (HMAC тощо) — pre-request скриптом на рівні папки. - **Environment `_V_SANDBOX` — мінімальний:** - `base_url` і ключі доступу (тип `default`, **значення порожні** — користувач вписує ключ у **Current value**, яке не синхронізується з командою; не копіюй ключі з інших оточень чи файлів скриптами). Тип `secret` не використовуй: Postman може перевести такі змінні у Vault і вимагати vault key, а порожня змінна дає запит без `Authorization`; - змінні, які скрипти зберігають з відповідей (`saves`: id клієнта, платежу, токена, NTID…); - id, згенеровані на початку флоу й потрібні кільком запитам (order id / idempotency base). Суми, валюта, картка, email, адреса, версія API, причини void/refund — **літералами в запиті**. Одноразові id, потрібні лише одному запиту, — `pm.variables.set(...)` у його pre-request. - **Тестові дані** — з документації провайдера (тестові картки, тестові токени). Дані Apple/Google Pay з документації або явно позначені як приклад формату. - **Тести — обов'язково для кожного запиту** (поле `tests` у spec; хелпер генерує `pm.test(...)`, формат ключів — у docstring `tests_script`: `status`, `max_time`, `json`, `one_of`, `exists`, `absent`, `type`, `match`, `equals_var`, `error`, `header`, `lines`). Значення беруться **лише з документації провайдера** (статуси, поля, коди помилок) — не вигадуй: - **позитивні**: HTTP-код; очікуваний статус операції з урахуванням варіанта (SMS → фінальний / списаний, DMS → авторизований, 3DS → `one_of` фінального статусу та «потрібна дія» + наявність redirect-URL); відлуння суми, валюти, режиму capture, order id (`equals_var`); наявність id, які зберігаються в `saves`, і scheme id для MIT-флоу; формат id (`match`); для Capture / Void / Refund — новий статус і суми (captured / refunded amount); - **негативні — окремі запити** в підпапці `Negative` кожного розділу (назва `N. … → <очікувана помилка>`): тестові картки з відмовами (decline, insufficient funds, 3DS failed), відсутній або невалідний ключ (власний `auth`), обов'язкове поле відсутнє, capture для SMS-платежу, void після capture, refund більший за суму, повтор з тим самим idempotency-ключем і іншим тілом — тільки ті, що описані в документації, з її кодами (`status` 4xx + `error`); - `[Private]`-запити: `status` дозволяє і успіх, і помилку «функцію не ввімкнено» (якщо її код відомий), в описі — що саме означає кожен результат; - спільні перевірки (час відповіді, JSON, логування помилки) — `folder_test` на версійній папці; **HTTP-код у `folder_test` не перевіряй** (інакше впадуть негативні тести) — лише в `tests` запиту. **Додати / оновити тести у вже створених запитах** — `tests `: замінює лише згенерований блок тестів (після маркера), не чіпаючи тіло запиту, `saves` і ручні правки користувача; перед генерацією візьми фактичні параметри запитів із Postman (`GET /collections/`), а не лише зі spec — користувач міг їх змінити. Нові негативні запити — через `sync`. Спільний тест версійної папки, що перевіряє HTTP-код, виправ (PUT папки з новим `events`). Запити й підпапки впорядковуй так, щоб **Collection Runner / newman** проходив флоу згори донизу (спільні id з попередніх кроків). - **Скрипти:** `saves` зберігає значення тільки при 2xx; перший запит флоу генерує спільні id через `pm.variables.replaceIn('{{$guid}}')`. ## 5. Перевірка 1. `postman_builder.py verify ` — у запитах не має бути змінних, яких немає в оточенні (крім локальних `pm.variables`), і в оточенні — зайвих змінних. 2. `tree ` — структура на місці. 3. Тести запуском: якщо користувач вписав **sandbox**-ключі (переконайся, що ключ тестовий — напр. `sk_test_`, а не бойовий) і дозволив — експортуй колекцію й оточення через Postman API (`GET /collections/`, `GET /environments/`) у scratchpad і прожени версійну папку: `npx -y newman run collection.json -e env.json --folder vN --env-var secret_key=<ключ від користувача>` (ключ не записуй у файли; бойовими ключами не запускай). Виправ запити й тести за реальними відповідями; розбіжності з документацією фіксуй у `methods.md`. Без ключів — лише `verify` і підсумок, що тести не запускались. ## 6. Звіт користувачу Статистика використання Claude — **обов'язкова частина звіту**. Перед звітом запусти `python3 <директорія цього skill-а>/session_stats.py` (з робочої директорії сесії) і встав отриману таблицю як розділ «Статистика роботи Claude» без змін: час (загальний / активний), модель, кількість викликів, токени (output, input, запис у кеш, читання з кешу), інструменти, кількість запусків build/update. Вартість у доларах не вигадуй — порадь `/cost` або `/usage`. Коротко: джерела, скільки методів знайдено по категоріях, матриця підтримки (SMS/DMS × 3DS / без 3DS / external MPI по кожному методу оплати; кількість тестів (позитивних / негативних) і результат прогону, якщо він був; окремо — статус MIT за scheme_id і розшифрованих даних Apple Pay / Google Pay з джерелами) і скільки варіантів запитів створено, чого немає в документації, шлях до `methods.md`, назва колекції/папки/оточення, що треба заповнити (ключі), що не перевірено запуском.