Skip to main content

​
Overview

The Make an API Call step lets a test hit a backend HTTP endpoint directly, without going through the UI. Use it to:
  • Set up state before the UI test runs (create a user, seed data, reset an account)
  • Assert on a backend response (status code, returned data)
  • Extract a value — such as an auth token — and reuse it in later steps
It works in both web and mobile tests.

​
How to access

  1. Type / in an empty test step to open the shortcuts menu
  2. Select Make an API Call
  3. Fill in the request using the structured editor (you don’t write the request by hand)

​
Request fields

​
Using variables and secrets

  • Template variables — reference values from earlier steps (e.g. extractions, scenario data, a saved response) anywhere that supports {{variables}}: the URL, header values, query params, and body.
  • Environment headers & secrets — pick a header from your environment in the Headers picker and it’s resolved automatically by name at run time (you don’t need a {{...}} template for it). This keeps secrets like API keys out of the test definition.
  • Reading fields from a saved response — when you Save Response To a variable, you can reach into the JSON with a dotted path, including array indices: {{loginResponse.token}}, {{loginResponse.user.id}}, {{searchResults.items.0.name}}.

​
Examples

GET and save a token, then reuse it
A later API Call can then send the token from the saved response:
Set up state before the UI test

​
Working with JavaScript steps

A response you Save Response To is also available to JavaScript steps as window.env.<name> — holding the raw response text. This lets you parse a payload, pull out the value you actually need, and save that for later steps. It’s the standard way to extract something buried in a JSON response — an email’s id, a token, or an item from a list. The pattern is three steps: 1. API Call — fetch and save the payload
2. JavaScript — parse it, operate on it, and return the value Read window.env.inboxData, run your logic, and return the result. Use save: to store the returned value under a name: save:emailMsgId
Return value (stored as emailMsgId):
3. Use it downstream — reference {{emailMsgId}} in any later step (a UI step, or another API Call):
window.env.<name> is the raw response text, so JSON.parse() it before reading fields. Throwing inside the script (throw new Error(...)) fails the step — handy as an assertion when the expected data isn’t present.
If you only need a simple field — not custom logic — you can skip JavaScript and read it directly with a dotted template, e.g. {{inboxData.messages.0.id}}. Reach for a JavaScript step when you need filtering, sorting, or conditional logic (like picking the newest “account activation” email above).

​
Notes

Only GET and POST are supported.
Set Expect Status to assert the backend behaved correctly — e.g. 200 for a successful login, or 401 when you’re deliberately testing a rejected request. A response outside the expected set fails the step.
Large responses are truncated when saved, so reference the specific field you need (e.g. {{loginResponse.token}}) rather than relying on the full body downstream. Enable Keep full response if a later step needs the entire body — for example, a JavaScript step that parses a long email body or a large JSON payload.
Press Cmd+Enter (macOS) or Ctrl+Enter (Windows/Linux) inside an API Call editor to save the step and collapse it — the same shortcut used elsewhere in Spur.