ClientResponseError у GPT Actions: після зміни schema перевірте Authentication
Зображення створене за допомогою штучного інтелекту OpenAI для публікації MIDITAUR Blog.
Під час розробки GPT з власними Actions можна зіткнутися з дуже оманливою ситуацією коли Action щойно працював, API відповідав правильно, серверна частина не змінювалася, але коли Ви редагуєте OpenAPI schema, зберігаєте конфігурацію GPT — і раптом замість нормальної відповіді отримуєте: ClientResponseError
Логічно почати шукати помилку саме там, де щойно були зміни: у schema, operationId, параметрах, endpoint або структурі відповіді.
Але перед глибоким debugging варто перевірити ще одну річ: Authentication, особливо якщо Action використовує: API key → Bearer
Практичне правило тут просте: CHANGE ACTION CONFIG → CHECK AUTH → TEST ACTION, або українською: ЗМІНИЛИ КОНФІГУРАЦІЮ ACTION → ПЕРЕВІРИЛИ AUTHENTICATION → ПРОТЕСТУВАЛИ ACTION
Authentication і schema — різні частини GPT Action
Це не припущення. OpenAI офіційно описує Action як конфігурацію з двох основних компонентів:
- способом, яким GPT автентифікується перед зовнішнім API;
- OpenAPI schema, яка визначає доступні операції API.
Для Authentication підтримуються, зокрема, None, API key та OAuth. API key для server-to-server доступу може використовувати режими Basic, Bearer або custom header.
Отже, правильна OpenAPI schema сама по собі ще не гарантує правильної авторизації запиту, бо це два окремі елементи конфігурації.
Чому Authentication варто перевіряти після змін
Є важлива деталь в офіційній документації OpenAI. У розділі про version history GPT прямо зазначено: якщо відновити старішу версію GPT, яка використовує Actions, після цього може знадобитися повторно налаштувати authentication.
Це не доводить, що звичайне редагування OpenAPI schema завжди скидає Bearer token, але це підтверджує важливіший для практичної роботи факт:
Authentication не варто вважати недоторканним станом, який за будь-яких змін конфігурації GPT гарантовано залишиться чинним.
Тому після зміни або перезбереження Action доцільно перевірити не лише schema, а й Authentication.
Є й практичні повідомлення про проблеми зі збереженням API key
У OpenAI Developer Community є повідомлення розробників про проблеми з API-key authentication у Custom GPT Actions.
Зокрема, описано випадок, коли API key після налаштування не зберігався належним чином. Автор розглядав це як можливий збій інтерфейсу, а результатом проблеми була відсутність належної авторизації запиту. Є й інші обговорення труднощів зі збереженням або повторним налаштуванням Bearer authentication.
Ці повідомлення не є офіційною специфікацією OpenAI й не доводять універсальної поведінки системи, але разом з офіційним попередженням про можливу необхідність повторного налаштування Authentication після відновлення версії вони дають достатню практичну підставу для простого контрольного правила:
після зміни конфігурації Action перевірте Authentication, перш ніж шукати складнішу несправність.
Що саме потрібно перевірити
Якщо зовнішній API використовує Bearer authentication, після змін відкрийте налаштування Authentication вашого Action і перевірте:
- чи залишився вибраним режим
API key; - чи встановлено тип
Bearer; - чи конфігурація Authentication виглядає коректною;
- чи не потрібно повторно ввести secret/API key.
Якщо ключ справді відсутній або authentication перестала бути налаштованою, введіть секрет повторно та збережіть зміни.
Сам Bearer token не слід переносити до OpenAPI schema, Instructions або повідомлень чату лише для того, щоб обійти нормальний механізм Authentication.
Після цього — обов'язковий тест
OpenAI рекомендує після конфігурації Action перевіряти його через Preview, тому після зміни schema або Authentication правильна послідовність виглядає так:
1. Змінити Action schema.
2. Переконатися, що schema проходить валідацію.
3. Відкрити Authentication.
4. Перевірити API key / Bearer configuration.
5. За потреби повторно ввести secret.
6. Зберегти зміни.
7. Запустити контрольний Action у Preview.
Ця коротка перевірка може заощадити значно більше часу, ніж повторний аналіз серверного коду.
Чому ClientResponseError може збити з пантелику
Тут потрібне важливе уточнення. ClientResponseError не є специфічною помилкою відсутнього Bearer token.
Тобто з самого факту появи ClientResponseError не можна зробити висновок:
Bearer token скинувся.
У Developer Community описано, наприклад, випадок, коли ClientResponseError виникав, хоча той самий endpoint нормально працював через Postman, а на сервері взагалі не було запису про отримання запиту. Є також повідомлення про періодичний ClientResponseError, коли Action то працював, то завершувався помилкою без відповідних змін серверної системи. Отже ClientResponseError має кілька можливих причин і Authentication — лише одна з речей, які потрібно перевірити.
Коли перевіряти Authentication одним із перших пунктів
Особливо доцільно почати саме з Authentication, якщо ситуація виглядає так:
- Action до цього працював;
- API та серверний код не змінювалися;
- ви щойно редагували або перезберігали конфігурацію Action;
- змінювалася OpenAPI schema;
- після цього Action перестав працювати;
- з'явився
ClientResponseError, помилка авторизації або інший generic execution error; - той самий API продовжує працювати з правильними credentials через інший клієнт.
Це ще не доказ втрати Bearer token, Але перевірити Authentication у такій ситуації значно раціональніше, ніж одразу переписувати API.
Не виправляйте те, що не ламалося
Без цієї перевірки легко потрапити в типовий debugging-сценарій, коли після появи помилки розробник починає змінювати:
schema → endpoint → request body → headers → API → reverse proxy → server → database, в той час, коли справжня проблема може знаходитися набагато ближче: GPT Action → Authentication
У результаті можна створити нові дефекти в системі, яка до цього працювала правильно. Тому при появі проблеми одразу після зміни конфігурації діє хороший інженерний принцип:
спочатку перевірте стан того, що могло змінитися разом із конфігурацією, і лише потім втручайтеся в уже перевірений API.
Чи доведено, що редагування schema скидає Bearer token?
Ні — і це важливо сформулювати точно. На момент підготовки цієї публікації не знайдено офіційної документації OpenAI, яка встановлювала б універсальне правило:
кожне редагування або перезбереження Action schema скидає Bearer token.
Тому таке формулювання було б надто категоричним, але натомість вже підтверджено три речі:
- Authentication і OpenAPI schema є окремими компонентами Action.
- OpenAI прямо попереджає, що після відновлення версії GPT з Actions authentication може потребувати повторного налаштування.
- Розробники публічно повідомляли про випадки проблем зі збереженням або використанням API-key/Bearer authentication у GPT Actions.
Цього достатньо для практичної рекомендації перевіряти Authentication після змін, але недостатньо, щоб називати автоматичне скидання token гарантованою властивістю GPT Actions.
Правильне формулювання правила
Тому робоче правило краще формулювати так:
Після зміни, перезбереження або відновлення конфігурації GPT Action повторно перевірте Authentication. Якщо Action використовує API key у режимі Bearer, переконайтеся, що authentication залишається коректно налаштованою, а за потреби введіть secret повторно. Втрата або неправильне застосування authentication може бути однією з причин помилки виконання, зокрема ClientResponseError, але ClientResponseError не є специфічним індикатором проблеми з Bearer token.
Висновок
Коли GPT Action перестає працювати відразу після зміни schema, природно підозрювати schema, але не завжди проблема знаходиться там, де була остання очевидна правка.
Authentication і OpenAPI schema в GPT Actions є різними частинами конфігурації. OpenAI навіть документує випадок, коли після відновлення версії GPT authentication може потребувати повторного налаштування, тому після будь-якої суттєвої зміни Action корисно виробити звичку:
SCHEMA → AUTHENTICATION → TEST
І якщо після редагування Action раптом з'явився ClientResponseError, перш ніж переписувати API перевірте Bearer authentication.
Це не єдина можлива причина помилки, але це одна з тих простих перевірок, які варто виконати першими.
Джерела
- OpenAI. “Configuring actions in GPTs”. OpenAI Help Center. Дата доступу: 15 серпня 2026.
https://help.openai.com/en/articles/9442513-configuring-actions-in-gpts - OpenAI. “Creating and editing GPTs”. OpenAI Help Center. Дата доступу: 15 серпня 2026.
https://help.openai.com/en/articles/8554397-creating-and-editing-gpts - OpenAI Developer Community. “Issue with GPTs Custom Action: API Key Authentication Settings Not Saving”. Дата доступу: 15 серпня 2026.
https://community.openai.com/t/issue-with-gpts-custom-action-api-key-authentication-settings-not-saving/552184 - OpenAI Developer Community. “‘Error saving draft’ when creating an authenticated action in a GPT”. Дата доступу: 15 серпня 2026.
https://community.openai.com/t/error-saving-draft-when-creating-an-authenticated-action-in-a-gpt/490733 - OpenAI Developer Community. “GPT Action Keeps Resulting in a ClientResponseError, Req. Never Even Sent to Server”. Дата доступу: 15 серпня 2026.
https://community.openai.com/t/gpt-action-keeps-resulting-in-a-clientresponseerror-req-never-even-sent-to-server/1128773 - OpenAI Developer Community. “GPT returns ClientResponseError when it tries to connect my server”. Дата доступу: 15 серпня 2026.
https://community.openai.com/t/gpt-returns-clientresponseerror-when-it-tries-to-connect-my-server/1311329 - OpenAI Developer Community. “GPT is getting flaky ClientResponseError”. Дата доступу: 15 серпня 2026.
https://community.openai.com/t/gpt-is-getting-flaky-clientresponseerror/1359709 - Publications Office of the European Union. “5.9.4. Bibliographic references”. Interinstitutional Style Guide. Дата доступу: 15 серпня 2026.
https://style-guide.europa.eu/o/opportal-service/isg?resource=en/5.9.4-bibliographic-references.html
CREDITS:
Зображення створене за допомогою штучного інтелекту OpenAI для публікації MIDITAUR Blog.