What Is an API Workflow

A login returns a token. The token unlocks a project. The project has an id you need before you can create anything inside it, and once you have, you still have to ask whether it is really there. Four requests, three of them depending on an answer that did not exist when you started.

That chain is an API workflow. Every product you have ever shipped runs on one. Most API clients still treat it as four unrelated tabs and a clipboard.

What an API Workflow Actually Is

An API workflow is an ordered set of HTTP requests where later requests consume values produced by earlier ones. Three parts have to be present:

Order. Step two cannot start before step one has answered, because it needs the answer.

Data movement. A value is lifted out of one response and placed into the next request. A token into a header, an id into a URL.

A verdict. Each step declares what a correct answer looks like. Without this you have a sequence of requests, not a test, and the chain will happily carry a null from step one to step four and report a green run.

You will see the same thing called a scenario, a journey, or a collection run depending on the tool. The shape does not change.

The Script You Would Write Instead

The usual escape hatch is a small script. Twenty lines of fetch, a couple of const token = assignments, run it with node. It works on day one. Then the API adds a header, someone needs the chain against staging, and the requests inside it drift from the ones in your API client.

The point of a workflow tool is that the chain stays made of requests, not of code that happens to send them.

Atrahasis Calls Them Flows

In Atrahasis API Client the feature is the Flow Runner, and a workflow is a flow: an ordered list of steps, up to fifty, plus an optional setup and teardown script around them. Steps do not have to be typed in. Pull them from your saved Box requests or the OpenAPI endpoints you designed in Projects, and a request you already trust becomes step one.

A step is the full request panel, not a stripped down form. Method, URL, body in any type the main editor supports, params, headers, per step variables, and the complete auth set including Basic, Bearer, API Key, OAuth 2 and OIDC. Pre-script and post-script run around it, assertions and extractions hang off the response, and any step can be toggled off without deleting it. If you can send the request on its own, you can make it a step.

Four Ways to Lift a Value Out of a Response

Extraction is how data moves. Each step can pull named values from its own response using one of four sources:

• JSON path, for example data.token or items[0].id
• Header, matched case insensitively
• Regex, which returns the first capture group when there is one and the whole match otherwise
• Status, when the code itself is the value you need

A name you extract becomes available everywhere later steps accept text:

GET  {{BASE_URL}}/projects/{{flow.projectId}}
Authorization: Bearer {{flow.token}}

URL, headers, body, params, form fields and auth configs all resolve. Scripts reach the same pool with at.flow.set("token", value) and at.flow.get("token"), so anything you can compute you can hand down the chain. A reference that never got filled is left in place as literal text rather than silently becoming an empty string, so a broken chain looks broken instead of looking like a bad server response.

Assertions Decide What Success Means

Every step carries its own assertions, checked against the response before the run moves on. They target the status code, response time, a header, a JSON path, or the body, and compare with the operator that fits: equals, contains, exists, greater than, matches regex, is type, and the negatives of each.

Expected values resolve variables too, so {{flow.userId}} in an assertion is compared against the id the API just gave you, not a fixture you pasted last month. A failed assertion marks the step failed even though the HTTP call itself succeeded, which is exactly the case a plain script misses.

Real APIs Blink

A rate limit, a cold container, a network hiccup on the third of ten iterations. Retry is configured per step: how many attempts, fixed or exponential backoff from a base delay, and which conditions are worth retrying. Network error, 5xx, and 429 are independent toggles, so a flaky gateway can be retried while a genuine 500 from your own service fails loudly. The retry count shows up in the results, so a step that only passes on the second attempt never looks healthy.

For the opposite need there is stop on failure, a toggle that halts on the first failed step and marks the rest as skipped. That is the mode you want gating a deployment. A delay between steps covers APIs that need a moment before a write becomes readable.

One Flow, Many Runs

The same flow can go deep or wide. Run it back to back for iterations to sample variance, or fan it out across parallel workers to hit the path concurrently. One or the other, never both at once.

The run view is the same view you designed in: duration, success rate, average response time, data transfer, a response time chart across the steps, and a per step table you can open to see the request, response, assertion results and script output inline. The slowest link gets flagged as a bottleneck when it runs past twice the average, and across three or more iterations, outlier runs and steps whose timings wander are surfaced on their own.

Author on the Desktop, Run in CI

A flow authored in the app runs unchanged on the atra CLI, with exit codes your pipeline can gate on and the same reports landing in your CI artifacts.

# Run a flow against staging
atra run auth-flow -f user-journey -e staging

# Ten iterations, back to back
atra run auth-flow -f user-journey -i 10

# Stop on the first failure, for CI gating
atra run auth-flow -f user-journey -c

Secrets stay where they belong: the flow references environment variables, and CI supplies the values. Reports come out as HTML, PDF, or JSON in OpenTelemetry format, shipped from an After All script to Slack, an email API, or wherever the pipeline collects them.

Scenarios, User Journeys, End to End

A workflow is the API shaped version of something a person actually does in your product. Sign up, verify the address, create the first project, invite a teammate. Testing endpoints one at a time proves each answers. It never proves the journey holds together, and the journey is the only part your users experience.

That gap is what end to end testing exists to close, and at the API layer a workflow is the cheapest honest way to close it. Every scenario your product supports becomes a chain you can run on demand and gate in a pipeline. The failures it catches are the ones no single request test can see: a field renamed between two services, a token whose scope quietly narrowed, an id that is a string on Tuesday and a number on Wednesday.

The Case for Microservices

In a monolith those four steps run inside one process, and a mismatch between them tends to fail at compile time. Split the product into services and the contract between them only exists at runtime. One user journey now crosses several services, each deployed on its own schedule, each with its own auth, its own store, and its own idea of what a valid id looks like. Every team's tests are green, and the path across them is still broken.

A workflow is the test that walks that path the way real traffic does, carrying real values from one hop to the next. When step three fails after a release that only touched one service, the run tells you which hop broke, what it answered, and how long it took. That is the difference between knowing your services are up and knowing your product works.

The Point

An API workflow is not a niche testing artifact. It is the actual shape of every feature you ship, and the only reason it usually lives in a throwaway script is that the client you were using could not hold it.