- Create an API workflow monitorGo to Monitors, choose "New monitor" and select API workflow.
- Define the first stepEnter a step name, method and URL, plus headers, body, status range and assertions as needed.
- Extract variablesChoose "Extract a variable" and enter a lowercase variable name and a JSON path, for example token and $.data.token.
- Add later stepsAdd steps that use the variable as {{token}} in the URL path or query, header values or body.
- Set schedule and createSet the interval and per-request timeout, then choose "Create monitor".
An API workflow monitor runs a sequence of HTTP requests on every check and fails at the first step that fails. It lets you test real user journeys, such as logging in and then fetching data with the returned token. API workflows are a Team plan feature.
Limits
- Up to 10 steps per workflow and up to 20 variables per workflow.
- Each request is one request unit. Team includes 50,000 request units per month across all workflows.
- The timeout applies to each request, not the whole run.
To estimate usage: a 3-step workflow checked every 5 minutes uses about 3 × 12 × 24 × 30 = 25,920 units per month.
Build the steps
Each step has a name, method, URL, optional headers (plain value or stored secret), an optional body and content type, an optional custom status range (default 2xx/3xx) and assertions. Use Move up and Move down to reorder steps.
Pass values between steps
Under each step, choose Extract a variable. Enter a variable name that starts with a lowercase letter and uses a-z, 0-9 or _, and a JSON path into that step's response, such as $.data.token. Later steps can use it as {{token}} in:
- the URL path or query (never the host),
- header values,
- the request body.
The form lists which variables are available at each step.
Example: log in, then read an order list
- Log in: POST
https://api.example.com/v1/sessionwith body{"client_id":"monitor"}and anAuthorizationheader from a stored secret. Assert$.data.tokenexists. Extracttokenfrom$.data.token. - List orders: GET
https://api.example.com/v1/orders?limit=1with headerAuthorization: Bearer {{token}}. Assert$.itemsexists. - Read one order: extract
order_idfrom$.items[0].idin step 2, then GEThttps://api.example.com/v1/orders/{{order_id}}and assert$.statusequals"open".
Good practice
- Use a dedicated monitoring account with read-only permissions.
- Avoid steps that create or delete real data, because they run on every check.
- Store all credentials as secrets; plain header values are stored as configuration.
- If you move a step that had a stored header value, enter the value again.
Frequently asked questions
Which plan includes API workflows?
The Team plan, which includes 50,000 request units per month. Each request in a workflow run uses one unit.
Can a variable change the host of a later request?
No. Variables can be used in the URL path or query, header values and body, but never in the host.
What happens when a step fails?
The run stops at the first failing step and the check counts as failed. Failures are confirmed like any other monitor before alerts go out.
