Baton Manual

Chapter 5

Sending a request

5.1The URL bar

Method, URL, and the two buttons that matter. — 1: Method; 2: URL, with {{variables}} highlighted; 3: Send — a square while it runs, which stops it; 4: Save to the workspace file; 5: Re-read the file, dropping edits
  1. Method
  2. URL, with {{variables}} highlighted
  3. Send — a square while it runs, which stops it
  4. Save to the workspace file
  5. Re-read the file, dropping edits
Figure 12: Method, URL, and the two buttons that matter.

The method 1 is a menu. The URL 2 takes {{variables}}, and shows them in colour: orange when the reference resolves against the active environment, red and underlined when it does not — so a typo is visible before you send. 3 sends. 4 saves the request to its file, and 5 re-reads that file, dropping whatever is unsaved — on a phone both sit in the top bar.

5.2What the tabs hold

Everything about the request, one tab each. — 1: Query string rows; 2: Request headers; 3: Authorization, or inherit it; 4: Body and its kind; 5: Scripts — the row scrolls for more
  1. Query string rows
  2. Request headers
  3. Authorization, or inherit it
  4. Body and its kind
  5. Scripts — the row scrolls for more
Figure 13: Everything about the request, one tab each.

1 is the query string, as rows you can switch off individually rather than editing by hand. 2 is request headers, the same way. 3 is authorization, covered in Authorization 8. 4 is the body and its kind. 5 is the pre-request and test scripts, and the row scrolls sideways to Variables. A count in the tab label tells you a tab has something in it without opening it.

5.3The execution pipeline

Pressing Send runs five steps in a fixed order, and the same order runs on the worker when a schedule fires.

One request, five steps. The worker does the same, so a scheduled run cannot behave differently.

Figure 14: One request, five steps. The worker does the same, so a scheduled run cannot behave differently.

5.4Reading the response

A response that came back, with tests that ran on it. — 1: Status, time, size, and the tests that ran; 2: Find in the body; 3: Pretty-print, copy, save
  1. Status, time, size, and the tests that ran
  2. Find in the body
  3. Pretty-print, copy, save
Figure 15: A response that came back, with tests that ran on it.

1 is the status, how long it took and how big it was, and at the end of the row a count of the tests that ran afterwards — green when they all passed. 2 searches inside the body, which is the fastest way through a long one. 3 pretty-prints the body, copies it, or saves it to a file.

5.5The other views of a run

The response panels tabs. — 1: What came back; 2: What actually went out; 3: Script output and test results; 4: Earlier runs; 5: Saved examples — the row scrolls
  1. What came back
  2. What actually went out
  3. Script output and test results
  4. Earlier runs
  5. Saved examples — the row scrolls
Figure 16: The response panel’s tabs.

1 is what came back. 2 is what actually went out — headers included, each labelled with where it came from, which settles arguments about whether a header was really sent. 3 is script output and test results. 4 is earlier runs of this request. 5, Examples, holds saved responses — see below — and past it, as the row scrolls, is the session cookie jar.

What really went out — including what was hidden. — 1: The URL as it actually went out; 2: A credential, hidden — and where it came from
  1. The URL as it actually went out
  2. A credential, hidden — and where it came from
Figure 17: What really went out — including what was hidden.

1 is the URL after every {{variable}} was resolved. 2 is a header Baton added from the request’s auth: the name and its origin are shown, the value is not. A secret that landed in a URL or a body reads back as {{secret:name}} for the same reason — this view exists to be pasted into an issue.

Each test by name, pass or fail. — 1: One line per test, with its name
  1. One line per test, with its name
Figure 18: Each test by name, pass or fail.

1 lists one line per test. A failing test names the expectation that did not hold, so the console is usually enough to see what changed.

Earlier runs of this request. — 1: Clear the list; 2: One run: status, environment, time and size
  1. Clear the list
  2. One run: status, environment, time and size
Figure 19: Earlier runs of this request.

History is per request and kept in .baton/ inside the workspace — so it is yours, and it records the request as it was written, never as it was resolved. 1 empties the list. 2 is one run: the status, the environment it ran in, when, how long it took and how much came back.

5.6Saved responses

A response worth keeping can be saved as an example: its status, the headers worth replaying and its body, in a file of its own beside the request. Examples are what a mock server answers with (Section 13), what an AI agent reads to learn what an endpoint returns, and what an OpenAPI import fills in from the spec’s own examples.

The Examples tab: what is saved, and a way to save what just came back. — 1: The saved examples — tap one to see it; 2: Keep the response you just got; 3: A file of its own, beside the request; 4: Edit, rename or delete it
  1. The saved examples — tap one to see it
  2. Keep the response you just got
  3. A file of its own, beside the request
  4. Edit, rename or delete it
Figure 20: The Examples tab: what is saved, and a way to save what just came back.

1 lists the saved examples by name and status; pressing one shows it. 2 saves the response you just received as a new one, with a name suggested from its status — ok for a 200. 3 names the file it lives in, list-users.examples.yaml next to the request’s own file, so saving an example never touches the request and shows up as a diff of its own. 4 edits the example on screen, and renaming and deleting sit beside it.