Зачем в Postman заполнять заголовки вручную

Что проверяют

Понимаете ли вы, что Postman и так отправляет часть заголовков сам, и зачем тогда вмешиваться руками. Следом обычно просят назвать заголовки, которые вы проверяли, и коды ответа, ожидаемые при их ошибке.

Как отвечать

Начните с автоматики. Postman сам добавляет Host, User-Agent, Accept, Accept-Encoding, Connection, Content-Length, служебный Postman-Token, а Content-Type выставляет по типу тела: raw и JSON дают application/json. Во вкладке Headers они скрыты, показать их можно переключателем hidden. Вкладка Authorization сама формирует заголовок Authorization.

Руками заголовки задают, когда автоматики не хватает:

• заголовки конкретного API: X-API-Key, X-Request-Id для трассировки, Idempotency-Key для платежей, заголовок тенанта;
• поведение сервера: Accept-Language для локализации, If-None-Match с ETag для проверки ответа 304, Accept для выбора формата;
• негативные сценарии: убрать токен (ждём 401), подставить токен пользователя без прав (403), отправить JSON с Content-Type: text/plain (415), запросить формат, который сервер не отдаёт (406);
• воспроизведение бага: взять запрос реального клиента через Copy as cURL в DevTools, импортировать в Postman и повторить один в один.

«Вручную» не значит вбивать каждый раз заново. Значения выносят в переменные окружения ({{token}}), авторизацию настраивают на уровне коллекции, а вычисляемые заголовки добавляют в pre-request script через pm.request.headers.add().

Где спотыкаются

Путают 401 и 403. Первый про отсутствующую или невалидную аутентификацию, второй про то, что пользователь известен, но прав не хватает.

Шлют JSON с типом тела raw Text и удивляются ответу 415 или пустому телу на сервере: Content-Type ушёл как text/plain.

Хардкодят боевые токены прямо в запросах и выгружают коллекцию в общий репозиторий. Токены утекают вместе с экспортом, поэтому секреты держат в Postman Vault или в локальных значениях переменных, которые не синхронизируются с командой.