Steps
Creating, configuring, and managing HTTP request steps within a flow.
What is a Step?
A step is a single HTTP request within a flow. Each step is a full-featured HTTP request with its own method, URL, headers, body, authentication, assertions, pre/post scripts, and variable extractions.
Creating Steps
There are three ways to add steps to a flow:
1. Create Manually
- 1Click the + button in the Step List header to open the inline create form
- 2Select the HTTP method and enter a name
- 3Press Enter or click the checkmark to create
2. Import from Box
Click the ▼ button next to the + button → From Box to import saved requests. Select one or more items from your Box and they'll be added as steps with all their configuration preserved.
3. Import from Projects
Click the ▼ button → From Projects to import endpoints from your API projects. Select endpoints from any project and module. Response contracts are also imported if available.
Configuring a Step
Click a step in the Step List to open it in the detail panel. The detail panel shows the same HTTP request editor you use for regular requests:
- •Request Line: Method, URL, and Send button (to test the step individually)
- •Request / Response toggle: Switch between configuring the request and viewing the response
- •Request tabs: Body, Params, Headers, Auth, Vars, Processors (pre/post scripts, assertions)
- •Retry tab: Configure retry behavior (max retries, delay strategy, retry conditions)
- •Response tabs: Body, Headers, Cookies, Detail, Contract
Tip: You can test any step individually by clicking its Send button. This sends the request without running the entire flow, useful for debugging a single step.
Managing Steps
| Action | How |
|---|---|
| Reorder | Drag a step by its handle (dots icon) and drop at the new position |
| Enable / Disable | Click the eye icon on hover. Disabled steps are skipped during execution. |
| Rename | Open the step menu (three dots) → Rename |
| Duplicate | Open the step menu → Duplicate. Creates a copy with all configuration. |
| Delete | Open the step menu → Delete. A confirmation dialog appears if enabled in preferences. |
Retry Configuration
Steps can be configured to automatically retry failed requests. Open a step and navigate to the Retry tab to configure:
- •Max Retries: How many times to retry before giving up (e.g., 3 retries = 4 total attempts)
- •Retry on Network Error: Retry when the request fails to reach the server (DNS, timeout, connection refused)
- •Retry on Server Error: Retry when the server returns 5xx status codes
- •Retry on Rate Limit: Retry when the server returns 429 (Too Many Requests)
Delay Strategies:
The Base Delay field sets the initial wait time in milliseconds. For fixed strategy, this is the delay between every retry. For exponential, this is the starting delay that doubles with each attempt.
Note: After execution, the retry count is shown in the step results so you can see how many attempts were needed.
Pre-Request & Post-Response Scripts
Each step can have JavaScript scripts that run before the request is sent and after the response is received. Configure them in the Processors tab.
Scripting API (at.*):
| Namespace | Available In | Methods / Properties |
|---|---|---|
| at.request | Pre (read/write), Post (read-only) | .url, .method, .headers, .body, .setHeader(), .removeHeader() |
| at.response | Post only | .status, .statusText, .headers, .body, .json(), .timing |
| at.environment | Pre & Post | .get(key), .set(key, value), .has(key) |
| at.flow | Pre & Post (flow execution only) | .get(key), .set(key, value), .has(key) |
Note: The script editor provides autocomplete for all at.* methods. Just type at. and the editor will suggest available namespaces and methods.
Step Status Indicators
During and after flow execution, each step in the list shows its status:
Auth Credentials & Persistence
The Auth tab of a step is a security boundary. Whatever you type into the credential fields behaves very differently from every other field on the step:
- •The auth type persists, the plain-text values do not. When the flow is saved — and therefore when it's committed to git — the selected type (Bearer / Basic / API Key / From Scheme) is kept along with structural fields (URLs, key names), but the actual token, username/password, and API key value are stripped to empty strings
- •Template references are preserved. If a credential field contains a variable reference like
{{api_token}}, Atrahasis treats it as a pointer, not a secret — it's stored verbatim. Anyone who pulls the flow from git gets the reference back, unchanged - •Plain values are memory-only. They survive as long as the flow panel is open in your session. Close the tab, reopen the flow, and any plain credential you typed is gone — you have to type it again
CLI & CI/CD implication: headless execution has no one to type credentials. That's why the pattern for CI flows is: reference a secret variable in the Auth tab ({{api_token}}), mark it as Secret in the environment panel (OS Secret or Vault), and let the CLI/CI runner supply the actual value from its own secret store at runtime. The committed flow carries only the reference — never the secret.