DEV Community: Mean

Stop sending README files as API docs — publish a live, versioned docs site with APIKumo

Mean — Wed, 13 May 2026 02:06:03 +0000

We've all been there. You build an API, you're proud of it, and then someone asks:

"Hey, where are the docs?"

And you paste them a GitHub link to a markdown file.

It works — technically. But it's not great. There's no try-it button, no version history, no search, no way for an AI assistant to understand your endpoints. Just a wall of text.

There's a better way, and it takes about 5 minutes to set up.

What APIKumo publishes

APIKumo is a full API workspace — you design requests, automate auth, version your work, and publish typed docs to your own subdomain. The publish step is what this post is about.

When you hit Publish on a collection, APIKumo gives you:

🌐 A live subdomain — your-api.apikumo.com (or your own domain)
🔍 Full-text search across every endpoint
📜 Scroll-spy navigation so readers always know where they are
🎨 Custom theme — your brand colors, logo, and name
🔢 Version selector — v1.0, v1.1, v2.0 all live at once
📋 Changelog so consumers know what changed between versions
▶️ Try-it — readers can fire real requests right from the docs (with their own auth)
🤖 AI docs chat — a built-in assistant that answers questions grounded in your endpoints
🔌 MCP endpoint — Claude, Cursor, and Continue can read and call your API automatically

How it works in practice

1. Build your collection normally

In APIKumo, you send requests the usual way — method, URL, headers, body, auth. The Monaco-powered editor handles JSON, XML, GraphQL, and more.

What makes it different: you also define request and response schemas — fields, types, enums, and examples. These become the docs.

GET /users/:id
→ 200 { id: string, email: string, role: "admin" | "member" }
→ 404 { error: string }

2. Snapshot a version

When your API is ready to ship (or already shipped), you take a version snapshot:

v1.0  →  snapshot  →  "Initial release"

You can keep editing in v1.1 without touching the published v1.0. Consumers on v1 see stable docs; v2 readers see the new surface. No separate repos, no copy-pasting.

3. Write your changelog

Each version gets a changelog entry. Plain text or markdown — whatever your team prefers.

## v1.1
- Added pagination to GET /users
- Deprecated X-Auth-Token header (use Authorization: Bearer instead)
- Fixed schema for POST /events body

Your API consumers see this in the version selector. They know exactly what changed and when.

4. Hit publish

One button. APIKumo generates the full docs site from everything you've built — schemas, examples, descriptions, changelogs — and deploys it to your subdomain.

The result looks like professional docs. Because it is.

The AI layer on top

Every published collection automatically gets two things that feel like magic the first time you see them:

Docs chat: An AI assistant trained on your actual endpoints. Not generic "how do I use an API" answers — specific answers like "What fields does POST /webhooks accept?" or "Show me how to paginate through orders."

MCP endpoint: A Model Context Protocol URL your team can plug into Claude, Cursor, or Continue. The AI reads your API surface and can help write the integration code — without hallucinating endpoints that don't exist.

Why this matters more than a README

README	APIKumo docs
Static text	Live, always up to date
No versions	v1.0, v1.1, v2.0 in one place
No try-it	Readers can fire requests in-browser
No search	Full-text search
No AI	AI chat grounded in your endpoints
No MCP	Claude / Cursor can call your API

If you're building APIs and still shipping documentation as a markdown file, give APIKumo's publish flow a try. It's free while in preview.

🌐 apikumo.com · Sign in with Google, GitHub, or Discord.

Stop writing auth boilerplate: API automation with pre/post processors in APIKumo

Mean — Tue, 12 May 2026 02:40:02 +0000

If you've spent more than a few hours testing APIs, you know the drill: copy the token from the previous response, paste it into the Authorization header of the next request, remember to re-sign the HMAC payload before sending, then manually check the response body for the field you actually care about.

It's tedious. It breaks your flow. And it's completely automatable.

APIKumo has a pre/post processor pipeline baked directly into every request — no plugins, no scripts stored somewhere off to the side, no separate test runner. Here's how it works and why it matters.

What are pre/post processors?

Every request in APIKumo can have two processor layers:

Pre-processors run before the request is sent — they can modify headers, compute signatures, inject dynamic values, or run custom JavaScript.
Post-processors run after the response arrives — they can extract values, assert on status codes or body fields, log output, or pass data forward to the next request.

Together they form a mini pipeline that makes your collection self-sufficient.

Common pre-processor use cases

1. HMAC request signing

Many payment, security, and internal APIs require requests to be signed with an HMAC-SHA256 digest computed from the request body + a timestamp. Without automation you'd compute this in a terminal, copy it, paste it — every single time.

In APIKumo, a pre-processor can do it for you:

const crypto = require("crypto");
const ts = Date.now().toString();
const body = request.body ?? "";
const sig = crypto
  .createHmac("sha256", env.SIGNING_SECRET)
  .update(ts + "." + body)
  .digest("hex");

request.headers["X-Timestamp"] = ts;
request.headers["X-Signature"] = `v1=${sig}`;

Save once. It runs on every send, automatically pulling SIGNING_SECRET from your environment — which can differ between staging and production.

2. Bearer token from environment

Got a /auth/token endpoint that you hit to get a JWT? Instead of manually copying the token, set it in an environment variable and reference it:

{{AUTH_TOKEN}}

Pair that with a post-processor on the login request (see below) and the token refreshes itself.

3. Timestamp nonces

Some APIs reject replayed requests by requiring a unique nonce or timestamp in a header. Pre-processors can inject Date.now() or a UUID before every send, without you thinking about it.

Common post-processor use cases

1. Extract and store a JWT

After a successful login, capture the token and save it to an environment variable:

const token = response.json.access_token;
env.set("AUTH_TOKEN", token);

Now every subsequent request in the collection that uses {{AUTH_TOKEN}} picks it up automatically. This is especially powerful when you chain a sequence of requests — login → create resource → fetch resource → delete — because each step feeds the next.

2. Assert on status and body

Post-processors double as lightweight tests:

assert(response.status === 200, "Expected 200 OK");
assert(response.json.id !== undefined, "Response missing id field");

Assertions surface clearly in the response panel. Run through a collection and you'll immediately see which steps passed and which didn't — no separate test suite needed.

3. JSONPath and regex extraction

APIKumo includes built-in JSONPath and regex extractors so you don't have to write custom JS for straightforward cases:

JSONPath: $.data.user.id → store in USER_ID
Regex: extract an order number from a plain-text response body
Header: capture a Set-Cookie value or Location redirect header

Environments tie it all together

Pre/post processors resolve {{variables}} from whichever environment is active. Switch from Staging to Production in one click and the same processors run against the right base URL, credentials, and secrets — without touching any processor code.

This is what makes collections genuinely reusable across teams. A new teammate clones the collection, fills in their own environment values, and every auth flow just works.

A real-world example: testing a webhook flow

Here's a simple three-request chain that would otherwise require constant manual copy-pasting:

POST /sessions — pre-processor injects HMAC signature; post-processor extracts session_id → SESSION_ID
POST /webhooks — pre-processor uses {{SESSION_ID}} in the body; post-processor extracts webhook_secret → WH_SECRET
POST /events/simulate — pre-processor signs the payload with {{WH_SECRET}}; post-processor asserts status 202

Three requests, zero manual copy-pasting, zero terminal tabs open on the side.

Why this beats a separate test runner

The usual alternative is to put this logic in a Postman test script, a shell script, or a pytest fixture. Those work — but they live outside your API workspace. Someone updates an endpoint and forgets to update the test script. The docs go stale. The scripts accumulate in a repo no one remembers to run.

APIKumo keeps processors inside the request, right next to the URL, headers, and body. When you publish that collection to a docs subdomain, the processors stay in the workspace while the docs reflect the actual schema — everything in one place.

Getting started

If you haven't tried APIKumo yet, it's free while in preview.

Go to apikumo.com and sign in with Google, GitHub, or Discord.
Create a new collection and add a request to an API you work with.
Open the Pre-processors tab on any request and try injecting a timestamp header.
Open Post-processors and add a JSONPath extractor or a status assertion.

The feedback loop is fast — you'll see exactly what each processor did in the response panel on every send.

API automation shouldn't require a separate tool. If your API client can't sign your requests, chain your calls, and assert on your responses without leaving the tab — it's time to upgrade.

— The APIKumo team

APIKumo gives every API collection an automatic MCP endpoint — here's why that matters

Mean — Mon, 11 May 2026 09:07:18 +0000

MCP (Model Context Protocol) is quickly becoming the standard way AI agents interact with external tools and services. Claude, Cursor, Continue, and others all speak MCP natively now.

The problem? Setting up an MCP server for your API used to mean writing a separate server, maintaining it alongside your actual API, and keeping it in sync whenever your schema changed.

APIKumo removes that entirely.

Every collection you build and publish in APIKumo gets an automatic MCP endpoint — no configuration, no separate server, no code to maintain.

How it works in APIKumo

When you publish a collection in APIKumo, you get three things out of the box:

A public doc page — with version selector, scroll-spy nav, changelog, and a live try-it console
AI chat grounded in your endpoints — users can ask questions about your API and get answers based on your actual definition, not hallucinated responses
An MCP endpoint — a live Model Context Protocol endpoint that any MCP-compatible AI agent can connect to immediately

The MCP endpoint is generated directly from your collection. That means it stays accurate by default — if you update a request in APIKumo, the MCP endpoint reflects it automatically.

What this looks like in practice

Say you've built a collection for a weather API in APIKumo. Once published, any AI agent that supports MCP can:

Discover your endpoints (GET /forecast, GET /current, etc.)
Understand the parameters, response shapes, and authentication requirements
Call the API natively — no custom tool definitions, no prompt engineering

Your API becomes an AI-native service the moment you publish it.

This is what "AI-ready docs" actually means — not just a page that looks good, but a surface that AI agents can read and act on.

Why this is a big deal for API developers

Most APIs are invisible to AI agents today. They exist as REST endpoints that humans know about, but agents can't discover or use without a human writing a wrapper.

With APIKumo's automatic MCP endpoint:

No MCP server to build or maintain — it's generated from your collection
No drift — your docs, AI chat, and MCP endpoint all come from the same source of truth
Works immediately — publish a collection, share the MCP endpoint URL, done

Try it

APIKumo is free while in preview.

Build your collection, publish it, and you'll see the MCP endpoint URL right in your dashboard — ready to drop into Claude, Cursor, or any MCP-compatible client.

APIKumo · Build, automate, and publish your API

Design requests, automate auth, version, and publish typed docs with AI chat and MCP built in.

apikumo.com

What APIs are you working with that you'd want to expose as MCP endpoints? Drop it in the comments.

I built an API workspace where docs write themselves — with AI chat and MCP built in

Mean — Sun, 10 May 2026 04:09:40 +0000

Most developers I know use at least three tools for a single API.

Postman or Insomnia for sending requests. Notion or a static site for
documentation. And some custom script — or a lot of manual copy-pasting
— for handling auth like HMAC signatures or chained tokens.

None of them stay in sync. The docs go stale. The auth scripts break.
And every new teammate has to figure out the whole setup from scratch.

That's why I built APIKumo.

What it is

APIKumo is an API workspace that covers the full lifecycle in one place:

Request builder — Monaco-powered editor, collections, environments, multi-tab, 20+ code generation targets
Pre/Post processors — automate auth before requests fire. HMAC signing, bearer token from env, JSONPath extraction, variable chaining, response assertions. No external scripts.
Doc publishing — publish to your own subdomain with version selector, changelog, scroll-spy navigation, and a live try-it console

The part I'm most proud of: Docs

API documentation has a reliability problem. You write it once,
it drifts from the actual implementation, and nobody trusts it after a month.

APIKumo generates docs directly from your requests and schemas —
so they stay accurate by default, not by discipline.

Every published collection also gets:

AI chat grounded in your real endpoints
Users can ask questions inside your doc page and get answers based on
your actual API definition. Not hallucinated. Not generic.

Automatic MCP endpoint
Every collection exposes a Model Context Protocol endpoint with zero
configuration. Claude, Cursor, Continue — any MCP-compatible AI agent
can read your API surface and call it natively.

The goal: docs shouldn't be a static page you maintain by hand.
They should be a living surface that works for both humans and AI agents.

Where it stands

APIKumo is free while in preview. I'm actively building and would
genuinely love feedback — especially from developers who've felt this
pain before.

👉 apikumo.com

Also launched on Product Hunt today if you want to support or leave feedback there.

What's the biggest pain point you've had with API tooling?
Would love to hear in the comments.