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:

1. POST /sessions — pre-processor injects HMAC signature; post-processor extracts session_id → SESSION_ID
2. POST /webhooks — pre-processor uses {{SESSION_ID}} in the body; post-processor extracts webhook_secret → WH_SECRET
3. 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.

1. Go to apikumo.com and sign in with Google, GitHub, or Discord.
2. Create a new collection and add a request to an API you work with.
3. Open the Pre-processors tab on any request and try injecting a timestamp header.
4. 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