HTTP-запрос в Tetiva состоит из метода, адреса, заголовков и тела. Главный источник истины — строка URL: query-параметры разбираются из неё во вкладку Params и собираются обратно, как только вы правите таблицу. Cookie живут отдельно от запроса — в хранилище воркспейса, которое переживает перезапуск приложения.
Если вы только начинаете работать с API, загляните в статью «Вопросы про API, которые неловко задать вслух». В ней без кода объяснено, что такое запрос, заголовки, методы и коды ответа.
Метод и адрес#
Метод выбирается слева от адресной строки: GET, POST, PUT, PATCH, DELETE, OPTIONS, HEAD. Цвета методов — по конвенции Swagger UI; тот же цвет повторяется на бейдже запроса в сайдбаре.
Отправить запрос можно двумя способами: Enter прямо в строке URL или Cmd/Ctrl+Enter в любом месте вкладки. Сохранить — Cmd/Ctrl+S; несохранённые правки помечаются точкой у полосы вкладок.
В адресе подставляются переменные активного окружения: напишите {{base_url}}/v1/users, и перед отправкой {{base_url}} заменится на значение. Подробности — в разделе окружения и переменные.
В ту же строку можно вставить готовую команду curl — она разберётся на метод, адрес, заголовки, тело и авторизацию, а уведомление перечислит, что приехало. Если вставка затёрла непустые заголовки, тело или авторизацию, рядом появится кнопка Undo. Разбор целиком — в разделе импорт и экспорт.
Query-параметры#
Вкладка Params показывает параметры текущего адреса. Связь двусторонняя: допишете ?page=2 в строке — строка появится в таблице; отредактируете ячейку, добавите или удалите строку — адрес пересоберётся. Снятый флажок убирает параметр из адреса, не удаляя строку из таблицы.


Отдельного хранилища у параметров нет: в запросе сохраняется именно URL. Поэтому отключённая строка живёт, пока открыта вкладка, а после переоткрытия таблица снова строится из адреса.
Значения в таблице кодируются по правилам URL, так что переменную в query удобнее писать прямо в адресной строке: после правки строки в таблице {{token}} превратится в %7B%7Btoken%7D%7D и уже не подставится.
Заголовки#
Вкладка Headers — пары ключ-значение с флажком у каждой строки. Флажок сохраняется вместе с запросом: отключённый заголовок не уходит на сервер и не попадает в команду Copy as cURL. Так удобно держать рядом два варианта Authorization и переключаться между ними, ничего не удаляя.


Заголовок Content-Type Tetiva подставляет сама по типу тела — application/json для JSON, application/xml для XML, application/x-www-form-urlencoded для формы, application/octet-stream для бинарного файла. Заданный руками Content-Type не перезаписывается — кроме формы с файлами: она всегда уходит как multipart/form-data, и заголовок с вычисленным boundary Tetiva выставляет сама. См. тело запроса.
Авторизация настраивается на вкладке Auth и превращается в заголовок или query-параметр уже при отправке. Кроме Basic, Bearer и API Key там есть OAuth 2.0, JWT Bearer, Digest и AWS Signature — см. авторизацию.
Cookie#
Tetiva держит собственное хранилище cookie на SQLite, отдельное для каждого воркспейса. Заголовки Set-Cookie из ответов сохраняются и прикладываются к следующим запросам того же домена — сценарий «логин отдаёт сессию, дальше работают остальные запросы» работает без ручного копирования.
Вкладка Cookies в ответе показывает две секции: Sent — что клиент приложил к этому запросу, Received — что пришло в Set-Cookie со всеми атрибутами. Ссылка «Manage cookies →» открывает менеджер: домены слева, таблица справа, можно добавить cookie руками, отредактировать, удалить одну, очистить домен или всё хранилище воркспейса.


Семантика — по RFC 6265, с одним осознанным упрощением:
- cookie без атрибута
Domain=считается host-only и матчится только на точный хост; сDomain=— на хост и поддомены. Добавленные вручную ведут себя как второй вариант; Set-CookieсMax-Age=0или датой в прошлом удаляет запись, поэтому серверный logout действительно чистит сессию;- cookie без явного
Path=получаютPath=/— RFC требует directory-default-path, здесь принято упрощение; - cookie без
ExpiresиMax-Age— сессионная: в менеджере у неё в колонке Expires написаноsession, как в DevTools браузера. Просроченные отсеиваются при чтении, сессионные хранятся до ручной очистки.
Описание запроса#
Описание запроса живёт на вкладке Docs — она есть у запросов всех четырёх протоколов. Редактор тот же, что у описания коллекции: Markdown, панель кнопок, таблицы и меню по /. Разобран он в коллекциях.
У запроса без описания вкладка показывает кнопку «Добавить описание»; как только описание появилось, на корешке Docs зажигается точка — открывать вкладку ради проверки не нужно.


Описание переживает экспорт в Postman и импорт обратно, видно агентам через MCP-сервер и вместе с синхронизацией попадает на другие ваши компьютеры.
Что происходит при отправке#
Клиент ждёт ответ 30 секунд и проходит до 10 редиректов подряд, прикладывая cookie на каждом шаге. Исключение — Digest и AWS Signature: для них редиректы выключены намеренно, чтобы подписанный или привязанный к nonce запрос остался на том адресе, для которого его собрали. Ответ открывается во вкладках Body, Headers, Cookies и Tests — разбор ответа описан в просмотре ответа, а вкладка Tests наполняется скриптами.