CLI reference

The requestarium command runs your saved requests and collections from a terminal or a CI job, using the same engine as the app's Send button. This page lists every command and option. To connect an AI agent, see CLI & MCP.

Before you start

You need:

• Node.js 20.10 or later.
• The requestarium command on your PATH. Install it from npm with npm install -g @requestarium/cli, or run it without installing as npx @requestarium/cli <command>. To update, run npm install -g @requestarium/cli@latest.
• A Requestarium account. requestarium login signs you in through your browser; on a machine without a browser, such as CI, use a personal API token from Settings → API tokens in the app (see Account & security). Tokens start with trt_.

Standalone binaries for macOS, Linux, and Windows, which need no Node.js, and a Homebrew formula are planned for a later release.

Check the install:

npm install -g @requestarium/cli
requestarium --version
requestarium --help

Quick start

# 1. Sign in once in your browser; the login is saved for later commands
requestarium login

# 2. Check the connection
requestarium status

# 3. See what you can run
requestarium collections

# 4. Send one request
requestarium run "Get user" --env Staging --var userId=42

# 5. Run a whole collection, stop at the first failure
requestarium run-collection "Users API" --env Staging --bail

Self-hosted servers

The CLI talks to Requestarium cloud (https://api.requestarium.com) unless you point it at another server:

requestarium login --token trt_… --api-url https://requestarium.mycompany.internal

Tokens belong to one server, so create the token in the app on the same server you sign in to. To switch for one command without changing the saved login, set the variable:

REQUESTARIUM_API_URL=https://requestarium.mycompany.internal requestarium run-collection "Users API" --env Staging

Naming things

Every command that takes a collection, folder, request, workspace, or environment accepts either its id or its name:

• Names are matched without regard to case: "users api" finds Users API.
• A request can also be named by its path in the collection: "Auth/Login" or "Admin/Users/List users".
• Quote names that contain spaces.
• If a name matches more than one item, the command stops and lists the ids. Use an id, or add --collection to narrow the search.

requestarium collections prints every id in square brackets.

Commands

login

Signs you in and saves the login, so later commands don't need it.

requestarium login [--api-url URL] [--workspace NAME] [--environment NAME] [--profile NAME]
requestarium login --token trt_… [--api-url URL] …

Without --token, login opens the Requestarium web app in your browser. Approve Connect Requestarium CLI there, and the CLI receives a personal API token named "Requestarium CLI on <your computer>". It shows up in Settings → API tokens, where you can revoke it. The CLI waits up to five minutes and prints the link in case the browser doesn't open.

A token is checked against the API before it is saved. To keep it out of your shell history, pipe it in:

pbpaste | requestarium login

The login is saved to ~/.config/requestarium/config.json (%APPDATA%\requestarium\config.json on Windows), readable only by you.

logout

requestarium logout [--profile NAME] [--all]

Deletes the saved login of the current profile, or of every profile with --all. If REQUESTARIUM_TOKEN is set in your shell, it still applies. To also revoke the token, delete it in Settings → API tokens.

profiles

Keeps several logins side by side, for example one per account or per server.

requestarium login --profile work                 # save a second login named "work"
requestarium profiles                             # list saved logins; * marks the one in use
requestarium profiles use work                    # use "work" from now on
requestarium run-collection "Users API" --profile default   # or pick one for a single command

Every command takes --profile NAME. REQUESTARIUM_PROFILE does the same for a shell or CI job. Without either, the CLI uses the profile chosen with profiles use, else default. A login saved by an older CLI is the default profile.

status

requestarium status

Shows the CLI version, API URL, which token is in use (only its first characters), your workspaces, how many collections you have, and the environments in each workspace. It exits with code 1 if the API can't be reached or rejects the token. doctor is the same command.

collections

requestarium collections [COLLECTION] [--workspace NAME]

Prints collections as a tree of folders and requests, with the method, URL, and id of each request. Name a collection to print only that one. ls is the same command.

Workspace: Main  [workspace 6f1c…]
📁 Users API  [collection 2b9e…]
  📂 Auth  [folder 81d0…]
    POST Login  {{baseUrl}}/login  [request 4c7a…]
  GET Get user  {{baseUrl}}/users/{{userId}}  [request 9e12…]

run

Sends one saved request.

requestarium run REQUEST [--collection NAME] [run options] [--quiet]

It also takes every run option.

Output:

✓ GET https://staging.example.com/users/42 → 200 OK in 84 ms · tests 2/2 passed · environment: Staging
  ✓ status is 200
  ✓ has an email

{"id":42,"email":"[email protected]"}

run-collection

Runs every request in a collection, or in one folder of it, in tree order: each folder's subfolders first, then its requests.

requestarium run-collection COLLECTION [--folder NAME] [--iterations N | --data FILE] [--delay MS] [--bail]
                            [--save-run] [--jira-on-failure PROJ] [run options]

It also takes every run option. run-folder is the same command.

Values that a script sets with pm.environment.set(...) are passed to the requests after it in the same iteration, so a login request can hand its token to the rest. Each iteration starts fresh. These values are not saved to the environment.

✓ Users API/Auth/Login  POST https://staging.example.com/login  200 · 112 ms
    ✓ logged in
✗ Users API/Get user  GET https://staging.example.com/users/42  500 · 40 ms
    ✗ status is 200 — Expected 500 to equal 200.

✗ Users API: 1/2 requests passed, 1 failed, 0 errors · tests 1/2 passed · 160 ms · environment: Staging

Run options

run and run-collection share these options.

Where variables come from on the command line, later ones winning: --env-file, then --env-var, then --var.

runs

Shows saved runs (see Run history), newest first.

requestarium runs [COLLECTION] [--workspace NAME] [--limit N] [--json]

✗ 2026-11-01 10:01:04  Users API  48/50 passed  ci main@d187326  env Staging  https://github.com/acme/api/actions/runs/7
✓ 2026-10-31 18:22:40  Users API  50/50 passed  cli feature/login@91ac2e0  env Staging

--limit is 1 to 100, default 20.

import

Creates a collection from a file made by another tool, or adds requests to one you have.

requestarium import FILE [--format auto|postman|openapi|requestarium|curl] [--name NAME] [--workspace NAME] [--dry-run]
requestarium import FILE --into COLLECTION [--folder PATH]
requestarium import --curl "curl https://api.example.com/users -H 'Accept: application/json'" --into "Users API"

The format is detected from the content. FILE can be - to read standard input. A new collection keeps the file's name, with (2) added when the name is taken; --name picks another. --folder puts everything under a folder: a folder's name or id, or a path such as Imported/Petstore from the collection root. Folders on that path that don't exist yet are created, so the same command can run again and lands in the same place. It works with --into and for a new collection. --dry-run shows what would be created, folders included. Anything that can't be carried over, such as file uploads or OAuth 2.0 settings, is listed after the import.

export

Writes a collection, or one folder of it, to standard output or a file.

requestarium export COLLECTION [--folder NAME] [--format requestarium|openapi3|swagger2] [--yaml] [--out FILE]

requestarium (the default) can be imported again, by the CLI or the app, with every setting. openapi3 and swagger2 describe the HTTP and GraphQL requests for other tools. --yaml, or an --out name ending in .yaml, writes YAML. Environment values are never exported.

publish-confluence

Publishes a collection's documentation to Confluence, the same page that Publish to Confluence on the collection's Overview uses. Run it in CI after a merge and the page stays in step with the collection.

requestarium publish-confluence COLLECTION [--folder NAME] [--space KEY] [--title TITLE] [--parent-page ID] [--no-bodies]
                                [--workspace NAME] [--dry-run] [--json]

The page lists every request in tree order with its folder path, method, URL, docs, and headers. Credential-looking header values are masked unless they are a {{variable}}. Publishing again adds a new version of the same page. A collection can have up to 500 requests on its page.

It needs the Confluence integration (Pro, Team, or Enterprise plan) connected by an organization admin in Settings → Integrations. The page is written as the connected Atlassian account.

requestarium publish-confluence "Users API" --space DOCS
# Published "Users API" in space DOCS: 12 requests, version 1.
# https://acme.atlassian.net/wiki/spaces/DOCS/pages/900

sync

Compares, pulls and pushes collections that are linked to a Git repository or a bucket (Git sync in the app).

requestarium sync status "Users API"          # what a pull and a push would change
requestarium sync pull "Users API"            # apply the repository's changes to the collection
requestarium sync push "Users API" --message "Add search endpoint"
requestarium sync push --all --check          # CI: exit 1 when something was not pushed

• COLLECTION or --all (every linked collection of the workspace; unlinked ones are skipped).
• A conflict (changed both in the collection and in the repository) fails the command with exit code 1, lists the

conflicting objects and changes nothing. --strategy ours keeps the collection's version of every conflict, --strategy theirs takes the repository's.

• --check changes nothing: push --check fails when there are changes that were not pushed, pull --check when

there are changes that were not pulled, status --check on either.

• --json prints one report with every collection's state, incoming, outgoing, conflicts and result.
• A push pulls incoming changes first, so the commit and the collection hold the same merged result.

Linking a collection, the sync history and restoring a version are done in the app.

snippet

Prints code that sends a saved request.

requestarium snippet REQUEST [--lang curl] [--collection NAME] [--env NAME] [--var key=value] [--raw] [--show-secrets]

Languages: curl, httpie, powershell, fetch, axios, python, go, java, kotlin, csharp, php, ruby. The request is built the way run sends it, with variables, inherited auth, and pre-request scripts, but nothing is sent. Secret values are shown as •••••• unless you add --show-secrets. --raw keeps the {{variables}} as saved.

env

Lists and edits environments.

requestarium env                                  # environments and their variable names, * = secret
requestarium env show Staging [--show-secrets]
requestarium env set Staging baseUrl https://staging.example.com
requestarium env set Staging apiKey - --secret    # "-" reads the value from standard input
requestarium env unset Staging apiKey
requestarium env create Staging [--group NAME] [--default] [--var key=value …] [--secret-var KEY]

env set keeps a secret variable secret when you change its value; --no-secret turns that off. Reading a value from standard input keeps it out of your shell history. Every command takes --workspace and --json.

cookies

Shows and clears the cookies saved in a cookie jar file (see Cookies).

requestarium cookies --cookie-jar cookies.json                    # domain, path, name, expiry; values masked
requestarium cookies list --domain api.example.com --show-secrets --cookie-jar cookies.json
requestarium cookies clear --cookie-jar cookies.json              # every cookie
requestarium cookies clear --domain api.example.com [--name sid] --cookie-jar cookies.json

--domain also matches subdomains. Both commands take --json. REQUESTARIUM_COOKIE_JAR can stand in for --cookie-jar.

completion

Prints a tab-completion script for your shell.

requestarium completion bash >> ~/.bashrc
requestarium completion zsh > "${fpath[1]}/_requestarium"
requestarium completion fish > ~/.config/fish/completions/requestarium.fish

Open a new shell afterwards.

update

Checks the npm registry for a newer CLI and prints how to install it: npm install -g @requestarium/cli@latest, or brew upgrade requestarium for the standalone binary. --json prints current, latest, updateAvailable and command.

requestarium update

The CLI also checks by itself, at most once a day, and prints a one-line notice on stderr after a command when a newer version is out. It does this only at a terminal: never in CI (when CI is set), when output is piped, for --json, or for mcp and completion. Set REQUESTARIUM_NO_UPDATE_CHECK=1 to turn it off. The check sends no data about you, your account or your collections; it only reads registry.npmjs.org/@requestarium/cli/latest. The last answer is kept in update-check.json next to the saved login.

Data-driven runs

--data FILE runs the collection once per row of the file. Each row's values are variables for that pass, so {{userId}} in a URL or pm.environment.get("userId") in a script reads the current row.

CSV: the first line holds the column names. Values can be quoted, and quoted values can hold commas, quotes (""), and line breaks.

userId,expectedStatus
1,200
2,200
999,404

JSON: an array of objects. Numbers and booleans become text; nested values become JSON text.

[{ "userId": 1, "expectedStatus": 200 }, { "userId": 999, "expectedStatus": 404 }]

requestarium run-collection "Users API" --env Staging --data users.csv

A file can have up to 10,000 rows. Row values win over the environment, and --var wins over row values. Reports number each pass as an iteration. --data replaces --iterations, so pass only one of them.

Run history

--save-run sends the run's results to Requestarium, so you and your team can see how a collection did over time, wherever it ran. requestarium runs lists them.

requestarium run-collection "Users API" --env Staging --save-run

Each saved run records:

• The collection (and folder), environment, counts of passed, failed, and errored requests and tests, duration, and the CLI version.
• Where it ran: ci or cli. In GitHub Actions, GitLab CI, CircleCI, Jenkins, Azure Pipelines, and Bitbucket Pipelines it also records the branch, the commit, and a link to the CI job. Elsewhere it takes the branch and commit from the git checkout in the current directory, if there is one.
• Per-request results: status, timing, and test results. Response bodies are kept only for requests that didn't pass, cut to 2,000 characters. Request headers aren't sent, and secret values are masked as in every report.

Saving needs the same permission as sending requests. If the run can't be saved, the CLI says why on standard error and still exits with the run's own result.

Jira on failure

--jira-on-failure PROJ reports a failed run to Jira, so a broken API in CI becomes a tracked issue without anyone copying logs:

requestarium run-collection "Users API" --env Staging --jira-on-failure OPS

When the run fails (a request fails, errors, or has a failed test), the CLI saves the run (it implies --save-run) and then:

• If an earlier saved run of the same collection (and folder) on the same branch is linked to a Jira issue that is not done yet, it adds a comment to that issue with the new failures and links this run to it. A collection that keeps failing while someone fixes it does not open a new issue every time.
• Otherwise it files a new issue in project OPS: a summary like "Users API: 2 of 10 requests failed", the environment, branch, commit and CI job, and the failed requests in a code block. The issue links back to the run in Requestarium, and the run shows the issue.

The issue type is Bug when the project has one, else the project's first type; --jira-issue-type Task picks another. A run that passes does nothing.

It needs the Jira integration (Pro, Team, or Enterprise plan) connected by an organization admin in Settings → Integrations, and an API token with write access to collections. The issue is created as the connected Jira account; the description names who ran it. Jira problems (plan, connection, unknown project) are printed on standard error and never change the exit code.

Secret managers

Requests can use secrets kept in AWS Secrets Manager, Azure Key Vault, or Google Cloud Secret Manager as ordinary {{variables}}. The CLI fetches them when a run starts, from your machine, with your own cloud sign-in. Requestarium never sees or stores your cloud credentials or the secret values, and the values are masked in reports, like secret environment variables.

Turn it on by adding these variables to an environment in the app (or with requestarium env set), so each environment can point at its own secrets:

Or pass them for one run: --aws-secret NAME, --aws-region, --aws-profile, --azure-vault URL, --gcp-secret NAME, and --gcp-project ID. Thunder Client's TC_AWS_SECRET_NAME, TC_AWS_REGION, and TC_AZURE_VAULT_URL work too, so environments brought over from Thunder Client keep working.

Which variables you get. An AWS secret that holds JSON key/value pairs, the usual kind, gives one variable per key: {"dbUser":"app","dbPassword":"…"} gives {{dbUser}} and {{dbPassword}}. A plain-text secret is one variable named after the secret. In Azure, every enabled secret of the vault becomes a variable named after it; Azure names can't contain _, so db-password is also available as {{db_password}}. In Google Cloud, each secret is a variable named after it, and a JSON secret gives one variable per key, as in AWS.

Signing in.

• AWS: keys in AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY (and AWS_SESSION_TOKEN) are used when set, as in most CI jobs. Otherwise the CLI asks the AWS CLI v2 for your current credentials, so aws sso login, profiles, and roles all work. The identity needs secretsmanager:GetSecretValue on the secret, and kms:Decrypt if it uses a customer-managed key.
• Google Cloud: a token in GOOGLE_OAUTH_ACCESS_TOKEN, or a service account key or user credentials file in GOOGLE_APPLICATION_CREDENTIALS, is used when set. Otherwise the CLI asks gcloud for a token, so gcloud auth login works, and so does workload identity federation set up by google-github-actions/auth. The identity needs the Secret Manager Secret Accessor role; using every secret of a project also needs permission to list them, such as Secret Manager Viewer.
• Azure: a service principal in AZURE_TENANT_ID, AZURE_CLIENT_ID, and AZURE_CLIENT_SECRET is used when set. Otherwise the CLI uses your az login session. The identity needs the Key Vault Secrets User role, or Get and List secret permissions in the vault's access policy.

In GitHub Actions, sign in with aws-actions/configure-aws-credentials, azure/login, or google-github-actions/auth before the run step; no secret values have to be copied into GitHub.

Values from a secret manager win over the environment's own values. A data file row, values set by scripts, and --var win over them. Secrets are fetched once per run; the MCP server keeps them for five minutes.

Cookies

Requests handle cookies the way a browser does. When a response sets a cookie (Set-Cookie), the CLI keeps it and sends it with the later requests that match it. That way, a login request followed by requests that need the session works with no extra steps.

• Scope. By default the cookie jar lasts for one command: every request of a run-collection shares it. Add --cookie-jar FILE to load cookies from a file and save new ones to it, so the next command continues the session. The file holds session tokens, so it is written readable only by you (mode 600). Keep it out of Git.
• Matching. Cookies follow the browser rules (RFC 6265): domain and subdomains, path, Secure (sent only over https and to localhost), Max-Age and Expires, __Host- and __Secure- prefixes. A response with Max-Age=0 deletes the cookie.
• Redirects. A cookie that a redirect sets (a login that answers 302 with Set-Cookie) is kept and sent to the next hop. Authorization is not passed on to another origin.
• Your own Cookie header. A Cookie header that the request sets is sent too. When it and the jar have a cookie with the same name, the request's value wins.
• Reports. Cookie values are masked: Cookie and Set-Cookie headers show ••••••.
• Turn off. --no-cookies doesn't store or send cookies.

In scripts, these work like in Postman:

pm.cookies.get('sid');               // the value of a cookie sent to this request's URL
pm.cookies.has('sid');
pm.cookies.toObject();               // { sid: '…', theme: 'dark' }
pm.response.cookies.get('sid');      // cookies this response set

const jar = pm.cookies.jar();
jar.set('https://api.example.com', 'lang', 'uk');
jar.get('https://api.example.com', 'lang');
jar.getAll('https://api.example.com');
jar.unset('https://api.example.com', 'lang');
jar.clear('https://api.example.com');

Jar methods work right away and return their result. They also take an optional Postman-style (error, result) callback. The Thunder Client-style pm.getCookies(url), pm.setCookie(url, name, value) and pm.clearCookies(url, name) work too; they return a Promise, but the change applies immediately.

How a run works

A run does what the app does when you click Send:

1. Variables resolve in this order, later ones winning: collection variables, folder variables (outer to inner), the environment, secret managers, a --data row, values set by scripts earlier in the run, then the command line (--env-file, --env-var, --var). Dynamic variables such as {{$guid}}, {{$timestamp}}, and {{$randomEmail}} work too.
2. Auth and timeout are inherited from the nearest folder or the collection when the request is set to inherit.
3. Pre-request scripts run: the collection's, then each folder's, then the request's.
4. If any {{variable}} is still unresolved, the request is not sent and is reported as an error, unless the request's "resolve variables before send" option is off.
5. The request is sent from your machine, so localhost, docker-compose, and VPN hosts work.
6. Test scripts run in the same order. Each pm.test(...) is reported as passed or failed.

See Scripts for the pm API and Environments for variables.

A request passes when all of its tests pass. A request with no tests passes when the status code is below 400. It is an error when it couldn't be sent (bad URL, unresolved variable, host unreachable, timeout, script error).

Settings

Environment variables override the saved login, so one machine can use different settings per shell or CI job.

Proxy and TLS settings apply to the requests the CLI sends for you, not to its own calls to the Requestarium API. A request whose Validate TLS certificates setting is off skips the check for that request only.

Which environment a run uses: --env, else REQUESTARIUM_ENVIRONMENT or the one saved by login, else the workspace's default environment, else none.

Exit codes

Use in CI

Create a dedicated API token for CI, store it as a secret, and pass it as REQUESTARIUM_TOKEN. No login step is needed.

GitHub Actions

name: API tests
on: [push, pull_request]
jobs:
  api-tests:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      checks: write   # for the test report step
    steps:
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      # Install the requestarium command here (see "Before you start").
      - name: Smoke tests
        env:
          REQUESTARIUM_TOKEN: ${{ secrets.REQUESTARIUM_TOKEN }}
          API_KEY: ${{ secrets.STAGING_API_KEY }}
        run: |
          requestarium run-collection "Users API" --env Staging --env-var API_KEY \
            --junit results.xml --html report.html --out report.json --save-run
      - uses: dorny/test-reporter@v1
        if: always()
        with:
          name: API tests
          path: results.xml
          reporter: java-junit
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: api-report
          path: |
            results.xml
            report.html
            report.json

Inside GitHub Actions the CLI also writes a table of results to the job summary and marks each failed request with an error annotation. Add --no-github to turn that off.

GitLab CI

api-tests:
  image: node:22
  script:
    # Install the requestarium command here.
    - requestarium run-collection "Users API" --env Staging --junit results.xml --out report.json
  artifacts:
    when: always
    paths: [results.xml, report.json]
    reports:
      junit: results.xml

Set REQUESTARIUM_TOKEN as a masked CI/CD variable in the project settings. GitLab then shows the JUnit results on the merge request.

Bitbucket Pipelines

The Requestarium pipe runs a collection without installing anything, puts the JUnit results on the pipeline's Tests tab, and saves the run with a link back to the pipeline:

pipelines:
  default:
    - step:
        name: API tests
        script:
          - pipe: docker://ghcr.io/nicktaporuk/requestarium-bitbucket-pipe:0.6.0
            variables:
              REQUESTARIUM_TOKEN: $REQUESTARIUM_TOKEN
              COLLECTION: "Users API"
              ENVIRONMENT: "Staging"
              ENV_VARS: "API_KEY"            # used as {{API_KEY}}, masked in reports
              API_KEY: $STAGING_API_KEY
              JIRA_PROJECT: "OPS"            # optional: file a Jira issue when it fails

Set REQUESTARIUM_TOKEN as a secured repository variable. The pipe also takes FOLDER, WORKSPACE, JIRA_ISSUE_TYPE, SAVE_RUN (default true), BAIL, ITERATIONS, DATA_FILE, TIMEOUT_MS, RETRIES, JUNIT_FILE (default test-results/requestarium.xml), HTML_REPORT, JSON_REPORT, API_URL, and EXTRA_ARGS for any other run-collection option. The step fails when the run fails.

JUnit report

--junit FILE writes one test suite per request run and one test case per pm.test. A request without tests gets one case that checks the status code is below 400, and a request that couldn't be sent is reported as an error. Jenkins, GitLab, Azure DevOps, CircleCI, and GitHub test-report actions all read this format.

JSON output

run --json prints one request result. run-collection --json prints a report with a results list of request results. --out FILE writes the same JSON to a file.

Every JSON report starts with these fields:

Request result:

Collection report:

Example: list the failed requests with jq:

requestarium run-collection "Users API" --json | jq -r '.results[] | select(.status != "passed") | "\(.path): \(.error.message // .statusCode)"'

Security

• The saved login file holds your token. It is created readable only by you; don't commit it.
• Request reports and snippets mask secret environment values, values from secret managers, --env-file and --env-var values, and credential headers, but response bodies are printed as received. Be careful when you share CI logs.
• Scripts are JavaScript and run on your machine with your permissions. Run only collections you trust, or set REQUESTARIUM_SCRIPTS=off.
• Revoke a token any time in Settings → API tokens; the CLI then stops working until you sign in again.

Troubleshooting

Limits

• Plan limits apply the same way as in the app. The Free plan has up to 3 collections, up to 30 requests in each collection, and up to 3 environments, and keeps 7 days of run history. When a limit is reached, the command stops with a message naming the limit. Sending requests and running collections, in the CLI, in CI or through MCP, is never limited.
• HTTP and GraphQL requests only. Run gRPC, WebSocket, Kafka, MQTT, RabbitMQ, and NATS requests in the app.
• Binary bodies and file uploads are not sent.
• Digest, NTLM, and AWS auth are not applied yet; the run reports a warning. Use --cert and --key for mutual TLS.
• import doesn't bring over file uploads, OAuth 2.0 and other auth types besides bearer, basic, and API key, or Postman environments (create them with requestarium env create).