Stop juggling base URLs and tokens — API environments in APIKumo

Every developer knows the pain. You have a working request against your local server, and then you need to test the same thing against staging — so you manually swap the base URL. Then prod. Then you realize you forgot to update the auth token. Then a teammate grabs your collection and nothing works because all the values are hard-coded to your machine.

There is a better way.

Environments and {{variables}} in APIKumo

APIKumo has a first-class environment system. Instead of hard-coding values into your requests, you wrap them in double curly braces:

{{baseUrl}}/users/{{userId}}
Authorization: Bearer {{accessToken}}

At send-time, APIKumo resolves every {{variable}} from whichever environment is currently active. Switching from dev to staging to prod is a single dropdown click — your requests don't change at all.

Setting up your first environment

Inside any collection, open Environments and create one per context: local, staging, production. Each environment holds key-value pairs:

Key	local	staging	production
baseUrl	http://localhost:3000	https://api-staging.example.com	https://api.example.com
accessToken	dev-token-abc	stg-token-xyz	(leave blank — set at runtime)
timeout	5000	10000	10000

Values are scoped per environment, so the same variable name resolves differently depending on context. Team members can have their own local overrides without touching the shared collection.

Using variables everywhere

Variables resolve in every field of a request:

• URL — {{baseUrl}}/v2/orders/{{orderId}}
• Headers — X-Tenant-Id: {{tenantId}}
• Body — {"user": "{{userId}}", "plan": "{{plan}}"}
• Query params — ?apiKey={{apiKey}}&region={{region}}
• Auth — any auth scheme that takes a token string

You can even nest them in JSON bodies inside the Monaco editor, which gives you full syntax highlighting and auto-complete while variable placeholders stay readable.

Capturing values automatically with post-processors

Here is where it gets powerful. Rather than manually copying a token from one response and pasting it into an environment, you can let APIKumo do it for you with a post-processor.

On your /auth/login request, add a post-processor:

// Extract the token from the response body and save it to the active environment
env.set("accessToken", response.body.token);

Now every time you run that login request, the token is automatically written to the current environment. The next request in the flow picks it up via {{accessToken}} — no clipboard gymnastics needed.

You can capture via:

• JSONPath — $.data.access_token
• Regex — match any pattern in the raw response
• Header — response.headers["X-Session-Id"]
• Custom JS — full scripting for anything non-standard

Pre-processors that generate values on the fly

Some values can't be stored statically — HMAC signatures, UNIX timestamps, nonces, request IDs. Pre-processors run before the request is sent and can write computed values into the environment:

// Generate a UNIX timestamp nonce
const nonce = Math.floor(Date.now() / 1000).toString();
env.set("requestNonce", nonce);

// Compute an HMAC-SHA256 signature
const payload = `${env.get("method")}\n${env.get("path")}\n${nonce}`;
const sig = hmac("sha256", env.get("secret"), payload);
env.set("signature", sig);

Your request headers then reference {{requestNonce}} and {{signature}} — the pre-processor fires first, so by the time the request goes out, every value is fresh and correct.

The workflow in practice

Here is a realistic flow for a payment API:

1. Activate staging environment — one click.
2. Run POST /auth/token — post-processor captures accessToken.
3. Run POST /payments/create — body uses {{amount}}, {{currency}}, {{customerId}}; header uses {{accessToken}}.
4. Post-processor captures paymentId from the response.
5. Run GET /payments/{{paymentId}}/status — uses the captured ID automatically.

The entire chain is repeatable, shareable, and environment-agnostic. Switch to production, run the same sequence, and nothing in the requests changes — only the values differ.

Sharing environments safely

When you share a collection with your team, environment structure travels with it (the keys), but sensitive values can be kept local. Anyone who clones the collection sees the variable names and knows what to fill in; they supply their own credentials without ever exposing yours in the shared file.

For non-sensitive defaults (base URLs, feature flags, timeout values), you can commit the full environment so new teammates are productive from the first run.

Wrapping up

The {{variable}} pattern sounds simple, but it is the foundation that makes everything else in APIKumo composable. Pre-processors write values in, post-processors capture values out, and environments keep it all context-aware. The result is an API workflow that travels cleanly from laptop to laptop and from environment to environment — with zero manual find-and-replace.

If you have not tried environments in APIKumo yet, sign in free and set one up in about two minutes.

— 🌐 apikumo.com • 📖 apikumo.com/blog • 📩 [e-mail]