Skip to content

Request

A request is one call: a method, a target, headers, a body, and a reference to auth. It is the unit everything else is built from — chains run them, tests assert on their responses, history records them.

A request can be hand-authored — you wrote it, it lives in a collection YAML file, you committed it — or spec-derived, generated from an endpoint in a bound spec source.

They are the same shape. The difference is who owns the definition:

Hand-authoredSpec-derived
Lives inA collection YAML you commitGenerated on each spec resolve
Survives a spec changeUntouchedRegenerated, with your edits re-applied as an overlay
Edited byYou, freelyYou, as an overlay over the generated base

These are reconcilable, not exclusive. Editing a generated endpoint does not fork it — Tinspec records the field groups that differ as an overlay and re-applies them after every refresh. Saving one as a request does fork it: the copy becomes hand-authored and stops tracking the spec.

A request names its protocol. At v0.1.0-preview.9 the values are http, grpc, graphql, websocket, and langgraph; a request with no protocol is HTTP.

The first four are authored in the generic request editor. langgraph is deliberately not in the protocol switcher — it has its own editor and run view, the way chains do.

Protocol changes what the editor shows, not how execution is reached. All of them go through one engine, so they share auth injection, {{variable}} resolution, the cookie jar, gateway rewriting, and history.

The full list, with types, is in Collection file format → Request. The ones worth knowing by name:

  • query is a first-class map, not something you hand-edit into the URL string. The Params tab edits it, and it is appended at send time.
  • body is text, a multipart form (rows of text and file parts), or a single raw file.
  • auth is a reference to an auth provider by name, plus optionally which sender to send as. A credential value can never appear here.
  • prerunChain names a chain to run before this request; its output variables merge into the environment for the send. This is how “log in, then call” becomes a single press of Send.
  • tests are assertions evaluated against this request’s own response.
  • useCookieJar opts a single request out of the shared cookie jar.

Any string field can contain {{name}}, resolved from the active environment at send time. Resolution happens in the engine, immediately before dispatch — so what you see in the editor is the template, and history records what was actually sent.

Unresolved variables fail the send by default rather than going out literally.