DEV Community: Mikołaj Badyl

Generating OpenAPI specs without writing a single line of YAML

Mikołaj Badyl — Wed, 25 Feb 2026 16:20:55 +0000

If you've ever tried to write an OpenAPI spec by hand, you know how painful it is. Hundreds of lines of YAML, manual endpoint definitions, request/response schemas - and if your API changes, you have to update it all again.

I ran into this problem while building Octrafic. The tool requires an OpenAPI spec to understand your API structure - and not everyone has one. So I built a scanner that generates it automatically from your source code.

How it works

The scanner uses a pipeline called OOPS that works in four stages.

1. Framework detection

It starts by reading your root config files - go.mod, package.json, requirements.txt and so on. From that it figures out your language and web framework without touching the rest of your codebase.

2. Route discovery

Using heuristics specific to the detected framework, it finds exactly which files contain your routing logic and endpoint definitions. It skips everything irrelevant - node_modules, test directories, etc.

3. Parallel endpoint extraction

Instead of dumping your entire codebase into the LLM context, it isolates each routing file and queries the AI in parallel. This keeps token usage low and extraction fast. It pulls out methods, paths, summaries, and request/response payloads.

4. Spec generation

Everything gets aggregated and formatted into a valid OpenAPI 3.1 YAML file, ready to use.

Usage

One command:

octrafic scan -p ./my-backend-project -o api-spec.yaml

Once the scan finishes, you can immediately start testing:

octrafic -u http://localhost:8080 -s api-spec.yaml

CI/CD support

The scanner runs completely non-interactively, so you can wire it into your pipeline:

export OCTRAFIC_PROVIDER=claude
export OCTRAFIC_API_KEY=your_key_here
export OCTRAFIC_MODEL=claude-haiku-4.5
octrafic scan -p . -o spec.yaml

Why I built this

Octrafic lets you test APIs using plain English instead of writing test scripts. But it requires an OpenAPI spec to understand your API structure - without one, it can't work.

The scanner removes that barrier. You point it at your project, get a spec, and go straight to testing - without writing a single line of YAML.

It's open-source, still early, feedback welcome.

GitHub: github.com/Octrafic/octrafic-cli
Docs: docs.octrafic.com

Stop writing API test scripts. Use plain English instead.

Mikołaj Badyl — Tue, 24 Feb 2026 16:13:00 +0000

Writing API tests is tedious. You either click through Postman manually, write JavaScript test scripts, or wrestle with curl flags you forget every time.

I built Octrafic to fix that - you describe what you want tested in plain English, and the AI handles the rest. This is a quick guide on how to actually use it.

Installation

Single binary, no runtime dependencies.

# Linux/macOS
curl -fsSL https://octrafic.com/install.sh | bash

# Homebrew
brew install octrafic/tap/octrafic

# Windows
iex (iwr -useb https://octrafic.com/install.ps1)

Set up your AI provider

Octrafic supports Claude, OpenAI, OpenRouter, Gemini, Ollama, and llama.cpp. You bring your own API key - nothing goes through my servers.

Run octrafic for the first time and it'll walk you through the setup.

If you want to run everything locally without any API key, Ollama works great:

ollama pull qwen2.5:7b

Then point Octrafic at it during setup.

Load your API

octrafic -u https://api.example.com -s openapi.json -n "My API"

-u - your API base URL
-s - path to your OpenAPI/Swagger spec
-n - project name

Start testing

Once you're in the TUI, just describe what you want tested:

test the login endpoint with valid credentials
test the login endpoint with a wrong password
test creating a new user and check the response structure
run edge cases on the /users endpoint

The AI figures out the right HTTP method, URL, headers, and payload based on your spec. It executes the request and shows you the response with a pass/fail result.

Authentication

Pass auth via CLI flags when starting a session:

# Bearer token
octrafic -u https://api.example.com -s spec.json \
  --auth bearer --token "your-token-here"

# API key
octrafic -u https://api.example.com -s spec.json \
  --auth apikey --key X-API-Key --value "your-key-here"

# Basic auth
octrafic -u https://api.example.com -s spec.json \
  --auth basic --user admin --pass secret123

Or use environment variables if you don't want credentials in your shell history or project files:

export OCTRAFIC_AUTH_TYPE=bearer
export OCTRAFIC_AUTH_TOKEN=your-token-here
octrafic -u https://api.example.com -s spec.json

One important thing - your actual tokens and passwords are never sent to the AI. The AI only knows the auth type and header names. Your credentials stay on your machine.

Export your tests

After running tests interactively, you can ask the AI to export them:

export these tests to postman
export tests as a shell script
export to pytest and name it test_users_api.py

You can also export a test plan before executing it, useful if you just want to generate tests and run them later.

Files are saved to ~/Documents/octrafic/tests/.

Run tests in CI/CD

For pipelines, use the octrafic test subcommand - no TUI, no prompts:

octrafic test \
  --url https://api.example.com \
  --path tests/api-tests.json \
  --auth bearer \
  --token $API_TOKEN

Or generate and run tests from a prompt directly:

octrafic test \
  --url https://api.example.com \
  --spec openapi.json \
  --prompt "test all user endpoints"

Exits with 0 if all tests pass, 1 if anything fails.

GitHub Actions example:

- name: Run API tests
  run: |
    octrafic test \
      --url ${{ secrets.API_URL }} \
      --path tests/api-tests.json \
      --auth bearer \
      --token ${{ secrets.API_TOKEN }}

Save your project

By default, new sessions are temporary. Use /save to persist your project, or watch for the temp indicator in the status bar.

That's the basics. It's open-source and still early, so if something doesn't work or you have ideas, open an issue.

GitHub: github.com/Octrafic/octrafic-cli
Docs: docs.octrafic.com

I added CI/CD support to my natural language API testing CLI

Mikołaj Badyl — Fri, 20 Feb 2026 20:03:43 +0000

Today I shipped v0.4.0 of Octrafic. Here's what changed and why.

If you haven't seen it before - Octrafic is a CLI tool that lets you test APIs using plain English instead of writing test scripts. First post here.

The problem with the previous version

Octrafic worked well interactively. You'd open the TUI, describe what you want tested, get results. Fine for day-to-day use.

But if you wanted to wire it into a CI/CD pipeline, it just didn't work. The TUI would block, waiting for input that was never coming.

Headless mode

The main addition in v0.4.0 is the new octrafic test subcommand. It runs non-interactively - no TUI, no prompts.

You can either run an existing test file:

octrafic test \
  --url https://api.example.com \
  --path tests/api-tests.json

Or generate and run tests on the fly from a prompt:

octrafic test \
  --url https://api.example.com \
  --spec openapi.json \
  --prompt "test all user endpoints"

Exits with 0 if all tests pass, 1 if anything fails. Easy to plug into GitHub Actions or any other pipeline.

Export to Postman, curl, pytest

Once you've run your tests interactively, you can ask the AI to export them:

export these tests to postman
export tests as a shell script
export to pytest and name it test_users_api.py

The exported files include auth configuration too, so they work out of the box. Useful if you want to run them outside of Octrafic or commit them to your repo.

/save command and temp project indicator

Small thing, but it was causing real confusion - you'd close the session and lose everything because you didn't realize the project wasn't saved. There's now a clear indicator in the UI and a /save command to make it explicit.

Still a solo project, still early days. But it's getting more useful with every release.

GitHub: github.com/Octrafic/octrafic-cli
Website: octrafic.com
Docs: docs.octrafic.com
Full release notes: docs.octrafic.com/releases/v0.4.0.html

API Testing Tools in 2026: Why I Built My Own (After Comparing All the Popular Ones)

Mikołaj Badyl — Tue, 17 Feb 2026 21:47:45 +0000

After years of using Postman for nearly every project, I started noticing the friction. The mandatory login, the Electron window eating my RAM, the team plan that suddenly costs way more than it used to. So I started exploring alternatives - and I genuinely tried all the popular ones. Some were great, some surprised me, and a few solved problems I didn't even know I had.

But none of them solved the problem I cared about most: making API testing feel like a natural part of the development loop rather than a separate ritual you have to context-switch into. That frustration eventually led me to build Octrafic. Before I get to that, let me give you an honest rundown of what's out there.

The Landscape: An Honest Comparison

Postman

Postman is the undisputed industry standard, and for good reason. The ecosystem is mature - collections, environments, team workspaces, mock servers, monitors, documentation generation. If your company is onboarding a team of 20 engineers onto a shared API workflow, Postman is probably still the answer.

The problem is that Postman has been aggressively moving upmarket. The free tier keeps shrinking, the desktop app requires you to be signed in, and it's noticeably resource-heavy for what is fundamentally an HTTP client. If you're a solo developer or a small startup, you're paying enterprise prices for features you'll never touch.

Best for: Enterprise teams with a real budget and a need for collaboration features.

Insomnia

Insomnia was my go-to replacement for a while. It's genuinely lighter than Postman, has a clean UI that stays out of your way, and its GraphQL support is excellent - auto-completion from your schema, query builders, the works.

The anxiety around Insomnia is mostly about ownership. Kong acquired it a few years back, and since then there have been some controversial moves around syncing and account requirements. The community forked it into Insomnium as a response. If you're okay with the uncertainty, it's a solid tool. If you want something more stable long-term, that uncertainty is a real factor.

Best for: Solo developers, especially those working with GraphQL.

Thunder Client

Thunder Client is a VS Code extension, which is either its biggest strength or a dealbreaker depending on your workflow. If you live in VS Code, and a lot of developers do, having your HTTP client as a sidebar panel is genuinely ergonomic. No context switching, no separate window, requests sit right next to your code.

The tradeoff is that you're in VS Code for everything. Advanced scripting, pre-request flows, CI/CD integration - Thunder Client handles the basics well but starts to feel limited for anything complex. It also means you're tied to the VS Code ecosystem.

Best for: Developers who use VS Code as their primary environment and mostly need quick endpoint validation.

Hoppscotch

Hoppscotch is impressive as a piece of software. It's fully open-source, runs in the browser, has a modern UI, and you can self-host the entire thing. There's no installation, which makes it great for quickly sharing a request with a teammate or testing something on a machine you don't control.

The limitation is that "runs in the browser" is both its superpower and its constraint. Offline capability is limited, and anything involving local environments or internal APIs requires some extra setup (their self-hosted agent). For pure open-source enthusiasm and accessibility, it's hard to beat.

Best for: Quick ad-hoc tests, teams that want a self-hostable open-source option, situations where installation isn't possible.

Bruno

Bruno is the tool that's gotten the most traction among developers frustrated with Postman's direction. Its core idea is elegant: API collections are stored as plain text files on your filesystem, which means they live in your Git repo alongside your code. No cloud sync required, no proprietary format.

It's offline-first by design, the UI is clean, and the philosophy resonates with developers who care about owning their data. The main caveat is that it's a newer tool - the ecosystem is smaller, some edge cases feel rough, and advanced scripting is still maturing. But the trajectory is good.

Best for: Teams that want their API collections version-controlled in Git, developers who want to avoid cloud lock-in.

The Gap I Kept Hitting

After going through all of these, I had a clear picture of the tradeoffs. But I kept running into the same wall, regardless of which tool I was using.

Manual GUI testing is fine when you're exploring a new API. But when you're deep in development - building a feature, refactoring an endpoint, dealing with a regression - the workflow becomes repetitive and tedious. Click, fill in params, click send, check response, repeat. Writing actual test scripts requires learning each tool's specific scripting API, which is its own investment.

More fundamentally: automation felt like an afterthought in all of these tools. The core experience is built around clicking through a GUI, and scripting/CI integration is layered on top. What I wanted was the inverse - a tool where automation and repeatability are the primary experience, and the interface facilitates that rather than fighting it.

I also noticed that nobody was taking AI seriously in this space. Not in a meaningful way, anyway. There were some autocomplete features here and there, but nothing that actually changed the testing workflow.

Why I Built Octrafic

So I built Octrafic - an AI-powered CLI tool for API testing, written in Go, fully open-source.

The core idea is simple: instead of clicking through a GUI or writing test scripts in a proprietary DSL, you describe what you want to test in plain English and the AI agent handles the execution.

# Start an interactive session against your API
octrafic --url https://api.example.com --spec path/to/spec

Then just describe what you want:

> Check if the /users endpoint returns paginated results with proper metadata
> Test that creating a user with a duplicate email returns a 409 conflict
> Verify that the authentication token expires after the documented TTL

The agent figures out what requests to make, runs them against your real endpoints, validates the responses, and tells you what it found. No test script to write. No learning a new assertion syntax.

If you have an OpenAPI spec, you can import it and Octrafic immediately understands your full API surface - endpoints, parameters, schemas, expected responses. This makes testing substantially more precise since the AI has context about what your API is actually supposed to do.

octrafic --spec ./openapi.yaml --url https://api.example.com

A few things I want to be upfront about: Octrafic requires your own LLM API key (OpenAI, Anthropic, or any OpenAI-compatible provider including local models via Ollama). The AI-powered workflow is powerful but different from traditional testing - it's better suited to exploratory and regression testing than to pixel-perfect assertion-based test suites. It's also a young project. Version 0.3.3 is out, and I'm actively building in public.

Side-by-Side Comparison

Tool	Type	Pricing	Standout Feature	AI-Powered	Open Source
Postman	GUI Desktop	Free / Paid plans	Team collaboration, full ecosystem	Partial	No
Insomnia	GUI Desktop	Free / Paid plans	GraphQL support, clean UI	No	Yes (forked)
Thunder Client	VS Code Extension	Free / Paid plans	IDE integration, zero setup	No	Partial
Hoppscotch	Web / Self-hosted	Free / Paid plans	No install, self-hostable	No	Yes
Bruno	GUI Desktop	Free	Git-friendly collections as files	No	Yes
Octrafic	CLI	Free (bring your own LLM key)	Natural language testing, CLI-first	Yes	Yes (MIT)

Where This Leaves Us

Every tool in this list has a legitimate use case. Postman makes sense for large engineering teams who need shared workspaces and are willing to pay for it. Thunder Client is the obvious choice if you're in VS Code all day and just need fast endpoint validation. Bruno is compelling for teams who want their API collections to live in Git like everything else.

I built Octrafic because I believe the future of API testing is conversational and automation-first. Describing what you want to verify and having an AI agent execute it is a fundamentally different experience than clicking through a GUI - and it fits better into how development actually flows when you're deep in a feature.

If that sounds useful, the project is open-source on GitHub and I'd genuinely appreciate feedback from people trying it on real APIs. And if you're happy with one of the other tools, that's completely valid - I still think Bruno and Hoppscotch are excellent.

Octrafic on GitHub · Documentation · octrafic.com

I Built an AI CLI That Lets You Chat With Your APIs

Mikołaj Badyl — Wed, 11 Feb 2026 00:10:35 +0000

Tired of writing Postman test scripts? I built Octrafic - a CLI tool where you describe API tests in plain English and AI executes them. It's open-source, runs locally, and supports multiple LLM providers.

Why I Built This

API testing sucks. You're either:

Clicking through Postman manually (doesn't scale)
Writing JavaScript test scripts (tedious boilerplate)
Using curl and forgetting the syntax every time

I wanted something faster: load your API spec, describe what you want tested, get results. The AI figures out the right HTTP requests, payloads, and validations.

How It Works

1. Install (single binary, no dependencies)

# Linux/macOS
curl -fsSL https://octrafic.com/install.sh | bash

# Homebrew
brew install octrafic/tap/octrafic

# Windows
iex (iwr -useb https://octrafic.com/install.ps1)

2. Configure your AI provider
Octrafic supports Claude, OpenAI, OpenRouter, Ollama, or llama.cpp. You bring your own API key - nothing goes through my servers.

# Run
octrafic

3. Load your API

octrafic -u https://api.example.com -s openapi.json -n "My API"

4. Start testing
The AI understands your API structure and generates appropriate requests based on natural language:

Technical Stack

Go - Single binary distribution across Linux, macOS, Windows. No runtime dependencies.

Bubble Tea - Terminal UI framework for interactive chat interface. Arrow key navigation, command history, proper scrolling.

Multi-LLM Support - Built adapters for Claude, OpenAI, OpenRouter, Ollama, and llama.cpp. Switch providers without changing your workflow.

Real Use Cases

API Exploration - Point it at an unfamiliar API and ask questions. What does this endpoint do?
What parameters does it accept?
Faster than reading docs.

Quick Testing - Test this endpoint with edge cases generates multiple requests with boundary conditions, missing fields, invalid data types.

Manual Testing Alternative - Instead of clicking through Postman, describe what you want tested. The AI executes and shows results.

Local Models - Privacy-focused? Run Ollama or llama.cpp locally. Your API data never leaves your machine.

Current State

It works. I use it daily for API testing. A few other developers are using it too.
That said, it's alpha software. Some features are rough. But the core is solid and I'm actively fixing issues.

GitHub repo: https://github.com/Octrafic/octrafic-cli
Website: https://octrafic.com
Try it. Open issues for bugs. PR's welcome if you want to contribute.