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.

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: Pre-request and test scripts
  1. Query string rows
  2. Request headers
  3. Authorization, or inherit it
  4. Body and its kind
  5. Pre-request and test scripts
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. 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 and size; 2: Tests that ran after the response; 3: Pretty-print, copy, save; 4: Find in the body
  1. Status, time and size
  2. Tests that ran after the response
  3. Pretty-print, copy, save
  4. Find in the body
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. 2 counts the tests that ran afterwards — green when they all passed. 3 pretty-prints the body, copies it, or saves it to a file. 4 searches inside the body, which is the fastest way through a long one.

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: The session cookie jar
  1. What came back
  2. What actually went out
  3. Script output and test results
  4. Earlier runs
  5. The session cookie jar
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. The tab after it, Examples, holds saved responses — see below. 5 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
  1. Clear the list
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.

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 (Section 14), 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 — pick 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 — pick 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.