DEV Community: Mesut Yakut

Atrahasis CLI

Mesut Yakut — Wed, 20 May 2026 23:19:05 +0000

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

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"}'

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}'

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"

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"

Or skip the install entirely:

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

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

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    |

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

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

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:

Did the request succeed?
Did it return the right thing?
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

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

What are Webhooks and How to Test Them

Mesut Yakut — Fri, 23 Jan 2026 15:47:24 +0000

You're building an e-commerce app. A customer completes a payment, and you need to update their order status, send a confirmation email, and notify the warehouse. How does your payment provider tell your app that the payment succeeded?

This is exactly where webhooks come in.

What is a Webhook?

A webhook is an automated HTTP request that one system sends to another when a specific event occurs. Think of it as a "reverse API" - instead of your app asking "Did anything happen?", the other system proactively tells you "Hey, something just happened!"

Traditional API polling works like this:

Your App: "Any new payments?" → Payment API: "No"
Your App: "Any new payments?" → Payment API: "No"
Your App: "Any new payments?" → Payment API: "Yes! Here's the data"

Webhooks flip this around:

Payment API: "A payment just completed!" → Your App: "Got it, thanks!"

This is more efficient, real-time, and reduces unnecessary API calls.

Real-World Webhook Examples

Webhooks are everywhere in modern software:

Stripe/PayPal sends a webhook when a payment succeeds or fails
GitHub notifies your CI/CD pipeline when code is pushed
Slack triggers workflows when messages are posted
Shopify alerts your inventory system when an order is placed
Twilio informs your app when an SMS is delivered

Every major platform uses webhooks to enable real-time integrations.

The Webhook Testing Challenge

Here's the problem: webhooks are notoriously difficult to test during development.

Challenge 1: You don't control when they fire

When testing a Stripe integration, you can't just "trigger" a real payment webhook whenever you want. You'd need to make actual payments, wait for processing, and hope the webhook arrives.

Challenge 2: Your local server isn't accessible

Webhooks need a public URL to send requests to. Your localhost:3000 isn't reachable from Stripe's servers. Developers often resort to tunneling tools, which add complexity.

Challenge 3: Inconsistent payloads

Real webhook payloads can vary. A payment webhook might include different fields depending on the payment method, currency, or account settings. Testing all variations is tedious.

Challenge 4: Timing and sequence issues

What happens if a webhook arrives before your database transaction commits? Or if webhooks arrive out of order? These race conditions are hard to reproduce with real services.

Challenge 5: Error handling is blind

When your webhook handler fails in production, you often don't know why. The external service just sees a 500 error. Debugging requires extensive logging and often can't be reproduced locally.

How Mock Servers Solve Webhook Testing

A mock server lets you simulate webhook behavior without depending on external services. Instead of waiting for Stripe to send a webhook, you configure your mock server to send it exactly when and how you need.

This approach gives you:

Full control over when webhooks fire
Predictable payloads that match your test scenarios
Local development without public URLs or tunnels
Edge case testing for timeouts, failures, and retries
Reproducible tests that run the same way every time

Webhooks in Mocklantis

Mocklantis provides a complete webhook simulation system. Here's how it works:

Creating a Webhook

In Mocklantis, webhooks are standalone entities that you configure once and bind to multiple endpoints. When any bound endpoint is called, the webhook fires automatically.

You configure:

Target URL: Where to send the webhook (your app's webhook handler)
HTTP Method: Usually POST, but supports all methods
Headers: Custom headers like Content-Type or authentication
Body: The payload to send, with dynamic template support

Template Variables

The real power comes from template variables. Your webhook payload can include data from the original request:

{ "event": "payment.completed", "orderId": "{{request.body.orderId}}", "amount": {{request.body.amount}}, "customerId": "{{request.body.customerId}}", "processedAt": "{{request.timestamp}}", "transactionId": "{{random.uuid}}" }

When a request hits your mock endpoint, Mocklantis extracts values from the request and injects them into the webhook payload. This creates realistic, dynamic webhooks that mirror real-world behavior.

Available template variables include:

{{request.path.id}} - URL path parameters
{{request.query.page}} - Query string parameters
{{request.body.field}} - JSON body fields (supports nested paths)
{{request.header.X-Custom}} - Request headers
{{request.timestamp}} - ISO timestamp
{{random.uuid}} - Generate unique IDs

Webhook Flow

Here's the sequence when a request arrives:

Client sends request to mock endpoint
Mocklantis returns the mock response immediately
Webhook fires asynchronously (doesn't block the response)
Your webhook handler receives the notification

This "fire-and-forget" approach mirrors how real webhook systems work. The webhook execution never affects your endpoint's response time or success.

Advanced Configuration

For realistic testing, Mocklantis supports:

Delay: Add latency before the webhook fires. Real payment processors don't send webhooks instantly - there's usually a 1-5 second delay. Simulate this to test your app's behavior during that window.

Retry Logic: Configure automatic retries if your handler returns an error. Set retry count (up to 10) and delay between attempts. Test how your app handles webhook redelivery.

Authentication: Support for Basic Auth, Bearer tokens, and API keys. Test that your webhook handler properly validates incoming requests.

Timeout Control: Set how long to wait for your handler's response. Test timeout scenarios without waiting forever.

Binding Webhooks to Endpoints

A single webhook can be bound to multiple endpoints. For example, an "Order Notification" webhook might fire when:

POST /api/orders (new order created)
PUT /api/orders/:id/status (status change)
DELETE /api/orders/:id (order cancellation)

This models real-world scenarios where the same external system needs to know about multiple types of events.

Practical Testing Scenarios

Testing Payment Flows

Create a mock POST /api/checkout endpoint that returns a success response, bound to a webhook that hits your POST /webhooks/payment handler. Now you can test your entire payment flow locally, including the webhook processing.

Testing Failure Handling

Configure a webhook with a short timeout and point it at a slow endpoint. Verify your app handles webhook timeouts gracefully. Then test retry behavior by returning 500 errors and checking that retries occur.

Testing Race Conditions

Add a 2-second delay to your webhook. Make a request and immediately query your database. Is the order in a "pending" state? Does your UI handle this correctly? These timing issues are nearly impossible to test with real services.

Testing Idempotency

Webhooks can be delivered multiple times. Configure retries and verify your handler doesn't create duplicate records or send duplicate emails when the same webhook arrives twice.

Best Practices

Always verify webhook signatures in production. While testing, you can skip this, but your production handler should validate that webhooks come from the expected source.

Make handlers idempotent. Use unique identifiers to detect and ignore duplicate deliveries.

Respond quickly. Return a 200 response immediately and process asynchronously. Webhook senders often have short timeouts.

Log everything. Webhook debugging is hard without detailed logs of what was received and how it was processed.

Test error scenarios. Don't just test the happy path. Simulate network failures, invalid payloads, and authentication errors.

Conclusion

Webhooks are fundamental to modern application architecture, enabling real-time communication between services. But their asynchronous, external nature makes them challenging to test during development.

By using a mock server with webhook support, you gain full control over the testing process. You can simulate any webhook scenario, test edge cases, and build confidence in your webhook handlers before deploying to production.

The next time you're integrating with a webhook-based service, consider setting up mock webhooks first. Your future self will thank you when debugging that mysterious production issue.

For this and more features: mocklantis.com
Download mocklantis: mock server

Mocklantis: Modern API Mocking Made Simple

Mesut Yakut — Fri, 12 Dec 2025 14:48:31 +0000

The Hidden Cost of Dependencies: Why Mocking Matters

Working with microservices architecture means living with dependencies. Your service talks to another service, that service talks to three more, and somewhere in this chain, there's a payment gateway, a notification service, and probably a third-party API with aggressive rate limits.

When everything is up and running, life is good. But here's the question nobody likes to ask: what happens when they're not?

How do you test a timeout scenario? How do you simulate a 503 from the payment service? How do you know your retry logic actually works before it matters?

These questions are uncomfortable because the honest answer is often "we don't" or "we hope for the best."

The Problems We Don't Talk About Enough

In microservices development, there are friction points that slow everyone down but rarely get addressed properly.

Dependencies block progress. Your service is ready, but the one you depend on isn't. Maybe another team is still building it. Maybe it's a third-party API with sandbox limitations. Maybe it's a payment gateway that only behaves correctly in production. Whatever the reason, you're waiting for something outside your control.

Unit tests create false confidence. Tests pass. Green checkmarks everywhere. But passing unit tests means your code works in isolation—with mocked interfaces that behave exactly as you programmed them. Real services don't behave that way. They timeout. They return unexpected responses. They fail at 3 AM on a Sunday.

Simulating failure is harder than building features. You need to verify what happens when a downstream service returns a 503. You need to test your circuit breaker. You need to confirm your fallback logic works. But actually creating these conditions? That's where teams give up and hope monitoring will catch problems in production.

Everyone mocks differently. One developer hardcodes JSON responses. Another writes a small Express server. Someone else uses a CLI tool with YAML configs. The staging environment is shared by four teams and constantly broken. "Works on my machine" becomes the team motto.

These aren't rare situations. This is Tuesday for most backend teams.

It's Not Just Microservices

Dependency problems aren't exclusive to microservices architecture. They exist wherever two systems need to talk to each other.

Frontend teams waiting for backend APIs to be ready. Mobile apps blocked because the server endpoint isn't deployed yet. Integration projects stalled because the third-party system has rate limits or sandbox restrictions.

The pattern is the same: your work is done, but you can't verify it because something else isn't available. You're blocked not by your own code, but by external factors.

This is where mocking becomes essential. Not as a nice-to-have, but as a fundamental part of how software gets built and tested.

Why Mocking Has a Bad Reputation

The concept of mocking is simple: create fake services that return predictable responses. Test your code against them. Simulate any scenario you need.

On paper, it's the perfect solution. In practice, most teams avoid it.

Traditional mocking means configuration files. YAML or JSON schemas. CLI commands. Learning another tool's syntax. Restarting servers every time you change a response.

You've already written the feature. You've already written unit tests. Now you need more setup just to simulate a service that someone else should have finished?

The friction isn't worth it. So teams test against unstable staging environments or skip integration testing entirely. Neither is good, but both feel more practical than fighting mock server configuration.

This is the real problem: mocking works, but the experience around it doesn't.

Mocklantis changes this.

Mocklantis is a free desktop application for creating mock servers. It runs locally on macOS, Windows, and Linux. It supports HTTP/REST endpoints, WebSocket connections, Server-Sent Events, and webhooks—all in one application.

But what makes it different is the experience. No configuration files. No CLI commands. No YAML schemas to learn. You open the app, create a server, add endpoints, and start testing. Changes apply instantly—no restarts, no rebuilds. Everything visual, everything immediate.

The distance between "I want to test this scenario" and "I'm testing this scenario" becomes seconds instead of hours.

Mocklantis in Action

The workflow is straightforward. You open the application, create a server on port 8080, add an endpoint—POST /payments/process, type a JSON response, set the status code. Done. The endpoint is live. Your service can call it immediately.

Need to test timeout handling? Add a delay. The change applies instantly—no restart, no config file, no terminal command. Need to test error scenarios? Change the status code to 503. Watch how your service responds.

Need dynamic data? Mocklantis supports template variables—UUIDs that regenerate per request, timestamps, emails, names, values that follow custom patterns. Fourteen different random variable types built in.

But HTTP/REST is just the beginning. Modern systems aren't just REST anymore.

WebSockets are everywhere—real-time dashboards, notifications, chat systems, live feeds. Mocklantis supports WebSocket mocking with three modes: conversational for request-response patterns, streaming for continuous data flow, and triggered streaming where a client message triggers a sequence of responses—perfect for AI-style interactions.

Server-Sent Events power streaming interfaces, especially in AI applications where responses arrive token by token. With Mocklantis, you configure events, set intervals, and define on-connect messages. Exactly what you need for testing streaming consumers.

Need to trigger external callbacks? Webhooks are built in. When an endpoint is called, Mocklantis can fire HTTP requests to other URLs with configurable auth, retry logic, and delays.

Everything visual. Everything immediate. No custom server code. No documentation required to get started.

Small Features, Big Impact

Some capabilities sound minor until you actually need them. Mocklantis gets these details right.

Live updates without restart. Change any endpoint while your service is running. Modify responses, add delays, switch status codes—all without restarting anything. Stay in flow. Experiment freely.

Automatic persistence. Every change saves immediately—500ms debounce, no save buttons. Close Mocklantis, come back tomorrow, everything is exactly as you left it.

Real-time request logs. See every request hitting your mock server as it happens. Headers, bodies, timing. Debug integration issues in seconds instead of adding logging statements everywhere.

Proxy mode. Mock some endpoints, forward others to real services. Isolate specific dependencies while keeping the rest of your stack intact.

Import from anywhere. Paste a cURL command, import an OpenAPI spec, or load a .mock file. Don't start from scratch when you don't have to.

Local-only operation. Everything runs on localhost. No cloud accounts. No data leaving your machine. No concerns about sensitive test data being logged somewhere.

None of these are revolutionary on their own. Together, they remove the friction that stops teams from testing properly.

The Friction Problem

Developer tools follow a pattern: more power means more complexity. Steeper learning curves. Thicker documentation. More Stack Overflow questions about basic setup.

But complexity isn't a requirement for capability. Usually it means nobody prioritized the user experience.

The best tools disappear into your workflow. You don't think about them. You don't fight them. They just work.

Mocklantis is built on this principle. Creating an endpoint shouldn't require reading documentation. Simulating a scenario shouldn't mean editing config files. Testing edge cases shouldn't feel like a separate project.

When mocking is easy, teams mock more. They test more scenarios. They catch more bugs before production. The tool's simplicity directly impacts code quality.

Confidence Compounds

Testing isn't about any single test. It's about the confidence that builds over time.

When simulating scenarios is easy, you simulate more of them. You verify error handling works. You confirm retry logic behaves correctly. You ship knowing your code handles edge cases—not hoping it does.

Reliable software comes from teams that can test thoroughly without fighting their tools. When the tooling gets out of the way, testing becomes a habit instead of a chore.

Wrapping Up

Dependency mocking is the most effective way to test services in isolation. It's how you verify that code handles real-world scenarios—not just happy paths, but failures, timeouts, and edge cases.

Most teams don't mock enough because the friction is too high. Configuration files, CLI commands, server restarts, learning curves. Rational trade-offs lead to less testing and more production surprises.

Mocklantis removes that friction. Visual interface. Instant updates. No configuration files. HTTP, WebSocket, and SSE support. Runs locally on macOS, Windows, and Linux.

It's free. You can start using it in seconds.

mocklantis.com

Get Started

Have fun.