DEV Community

Mesut Yakut
Mesut Yakut

Posted on • Originally published at mesutyakut.Medium

Atrahasis CLI

#cli #apiclient #testing #webdev

Atrahasis CLI - atra
atra is the official command-line interface of Atrahasis a modern API workspace that covers everything from a single HTTP request to multi-step flow tests and full load benchmarks. The desktop app gives you the full visual experience; atra is what you reach for when your hands are already on the keyboard.
It's built in Rust and shipped as a single static binary. No runtime, no dependencies, no setup ceremony - install once, run anywhere.

The problems atra is built to solve

Working with APIs from the terminal has always felt like assembling a toolkit by hand. You need one thing for ad-hoc requests, another to chain them, another to put them under load, and a fourth to make any of it run in CI. Each piece comes with its own config format, its own scripting model, and its own gaps.

Atrahasis CLI was built to flatten all of that into a single, coherent tool:
Opaque latency: "It was slow" tells you nothing. atra breaks every request into DNS, TCP, TLS, server response, and download phases so you see exactly where the time went.
Assertions as an afterthought: Most CLIs hand you a body and a status code and leave the verification to you. atra has assertions built in for status, headers, body, JSON path, and response time with proper exit codes so they drop straight into CI.

Multi-step API testing: Real workflows are "log in → create → verify → clean up." atra runs them as flows with shared state, variable extraction, and a live terminal dashboard that shows you each iteration as it happens.
Load testing in a separate world: Stress and spike testing usually means learning yet another tool. atra runs the same step definitions as load tests, with full percentile metrics in your terminal - no second toolchain to maintain.

Modern protocols: HTTP/3 is the present, not the future. atra speaks HTTP/1.1, HTTP/2, and HTTP/3 (QUIC) natively, with automatic protocol negotiation.

One-Line Install
Pick your channel, Atrahasis CLI ships natively for macOS, Linux, and Windows:

# Homebrew (macOS)
brew install atrahasisdev/tap/atra

# npm
npm install -g @atrahasis/cli

# curl (macOS/Linux)
curl -sSL https://cli.atrahasis.dev | sh

# wget
wget -qO- https://cli.atrahasis.dev | sh

# PowerShell (Windows)
irm https://cli.atrahasis.dev | iex
Enter fullscreen mode Exit fullscreen mode

No Node, no Python, no Docker required at runtime. Every install method drops a native binary on your PATH. atra - version and you're done.
There's also a built-in self-updater:
atra update

Familiar Syntax, curl-Compatible Flags

If you know curl, you already know most of atra. Headers, methods, body data, basic auth, follow redirects, cookies the flags map straight across:

atra https://api.example.com/users \
  -H "Authorization: Bearer my-token" \
  -d '{"name": "Alice"}'
Enter fullscreen mode Exit fullscreen mode

But atra also adds triple-mode syntax, so the same request can be expressed as:

# Shorthand - auto-detects JSON, sets Content-Type
atra POST https://api.example.com/users name:Alice age:30

# Or fully explicit
atra POST https://api.example.com/users \
  -H "Content-Type: application/json" \
  -d '{"name": "Alice", "age": 30}'
Enter fullscreen mode Exit fullscreen mode

Where Did the Time Go? Request Tracing

Most HTTP clients tell you the response time. atra tells you where it was spent.
Add -t (or --trace) to any request, and you get a connection waterfall directly in the terminal:

You see DNS, TCP, TLS, request send, server response, and download phases broken out individually. That 600ms latency you've been hunting? It's right, there was it the TLS handshake, the upstream's slow first byte, or the download itself?
No flame graphs, no packet capture, no extra tooling. One flag, full visibility.

Assertions That Speak CI/CD

Atrahasis CLI has first-class assertion support built-in, with no extra parser or wrapper script. Each assertion exits with code 1 on failure, which means atra slides into any CI pipeline as easily as curl did, but actually tells you whether your API is healthy:

atra GET https://api.example.com/users \
  -a "status eq 200" \
  -a "$.age eq 30" \
  -a "body contains Alice" \
  -a "header content-type contains xml" \
  -a "response_time lt 10"
Enter fullscreen mode Exit fullscreen mode

You assert against:
Status codes
JSONPath values as ($.age equals 30)
Body contents
Headers
Response time thresholds

In a GitHub Actions step:

- name: Smoke test
  run: |
    curl -sSL https://cli.atrahasis.dev | sh
    atra GET https://api.example.com/health \
      -a "status eq 200" \
      -a "response_time lt 500"
Enter fullscreen mode Exit fullscreen mode

Or skip the install entirely:

- name: Smoke test
  run: npx --yes @atrahasis/cli GET https://api.example.com/health -a "status eq 200"
Enter fullscreen mode Exit fullscreen mode

Flow Runner - Multi-Step API Tests with Live Dashboards

Real-world API testing isn't a single request. It's "log in, then create an order, then fetch it back, then verify the state changed."
That's what the flow runner is for. You describe a multi-step flow in JSON, atra runs it with shared state, pre/post scripts, variable extraction between steps, and real-time terminal UI:

atra run api-tests -f bulk-create-orders -i 4

OR

atra run api-tests -f bulk-create-orders -p 5
Enter fullscreen mode Exit fullscreen mode

What you get in the terminal:

  • Live response-time chart per step, per iteration
  • Throughput and success rate summaries
  • Anomaly detection atra highlights when a particular iteration is significantly slower or faster than the average for that step
  • Step-by-step results with HTTP status, latency, and asserted outcomes

Flow variables ({{flow.userId}}), environment variables ({{base_url}}), and random generators ({{random.email}}), ({{random.uuid}}) are first-class. Chain a login response into the next request without writing a single line of glue code.

And because exit codes propagate, the same flow can run as a smoke test in CI, as a release gate, or as a local sanity check. One artifact, three jobs.

Load Testing in the Terminal

The same step definitions that drive your flow tests can drive a load test. No second toolchain, no second scripting language, no second mental model just run the same spec with a load profile:

atra run spec-group -s create-order -t stress

Profiles included out of the box:

| Type   | Virtual Users | Ramp  | Duration |
|--------|---------------|-------|----------|
| load   | 50            | 30s   | 60s      |
| stress | 200           | 10s   | 60s      |
| spike  | 300           | 2s    | 30s      |
| soak   | 30            | 30s   | 5min     |
| custom | yours         | yours | yours    |
Enter fullscreen mode Exit fullscreen mode

Live terminal dashboard shows:

  • Avg, p50, p90, p95, p99 response times, updated every second
  • Throughput (requests/second) over time
  • Error rate chart
  • Active virtual users ramp
  • Per-step breakdown with full percentile distribution

Reports can be exported to HTML, PDF, or OpenTelemetry JSON for handoff to dashboards downstream.

HTTP/3, Natively

Most CLIs added HTTP/3 as an afterthought, requiring custom builds or feature flags. atra ships with HTTP/3 (QUIC) support compiled in. Force any protocol or let atra negotiate:

atra GET https://api.example.com --http3
atra GET https://api.example.com --http2
atra GET https://api.example.com --http1.1
Enter fullscreen mode Exit fullscreen mode

Connection pooling and protocol negotiation happen automatically, so when you don't force a protocol, atra picks the best available and reuses connections across redirects and flow steps.

A Real-World Walkthrough

Imagine you've just shipped a new endpoint and want to validate it end-to-end before flipping the feature flag. With atra, that's three commands you can put in a single script:

# 1. Smoke test the new endpoint
atra GET https://api.example.com/v2/orders \
  -B my-token \
  -a "status eq 200" \
  -a "$.data is_type array"

# 2. Run the integration flow (login → create → fetch → cancel)
atra run flows -f order-lifecycle -e staging

# 3. Apply 30 seconds of load to see if it holds under traffic
atra run specs -s order-create -t spike -e staging
Enter fullscreen mode Exit fullscreen mode

If any step fails - assertion mismatch, flow step error, threshold breach the exit code propagates, your CI fails, and you have a colorful terminal report explaining exactly what went wrong. No tab-switching, no copy-paste from different tools, no "wait, what was the curl command again?"

That same script works on your laptop, in GitHub Actions, in GitLab CI, in a Kubernetes Job, or on a Raspberry Pi running Linux. Single binary. Zero runtime. Same output everywhere.

Why Bother?

Because tooling fragmentation is a tax we've been paying for too long. Every new tool means a new config format, a new install dance, a new way to ask the same three questions:

  1. Did the request succeed?
  2. Did it return the right thing?
  3. Did it return in time? atra makes those three questions one command, with rich output, on every OS, in every CI. Ad-hoc requests, multi-step flows, load tests - same binary, same syntax, same dashboards. That's the whole pitch.

Get Started 

npm install -g @atrahasis/cli
atra https://api.example.com -a "status eq 200" -t
Enter fullscreen mode Exit fullscreen mode

That's it.

curl: curl -sSL https://cli.atrahasis.dev | sh 
wget: wget -qO- https://cli.atrahasis.dev | sh
npm: npm install -g @atrahasis/cli
homebrew: brew install atrahasisdev/tap/atra
powershell: irm https://cli.atrahasis.dev | iex

Platform: Atrahasis
Desktop App: Api Client
CLI Documentation: Atra CLI

Top comments (0)