You have forty endpoints in a project, and every single one needs the same Authorization: Bearer ... header and an X-Api-Version header on every call. Adding those two lines by hand to each request is slow, and worse, it drifts. One endpoint gets the token, another gets forgotten, and you burn an afternoon chasing a 401 that only shows up on three routes out of forty.
There’s a better way. Apidog lets you define parameters once and have them apply to every request automatically. Set the header at the project level, reference your token as a variable, and every endpoint inherits it without you touching a single request. This guide walks through the three documented levers for this: global parameters, environment variables, and a folder-scoped script fallback. You’ll finish with a working setup that attaches an auth header and a version header to everything, plus a way to prove the header actually went out on the wire. If you want the deeper background on variables first, our guide to mastering variables in Apidog pairs well with this one.
The idea of a request that carries a standard header on every call is not unique to Apidog. It’s the same pattern the MDN HTTP headers reference describes: a small set of key/value pairs that ride along with each request. Apidog’s job is to let you set that set once.
What “global parameters” actually means
A global parameter in Apidog is a request parameter that applies across the whole project rather than to a single endpoint. You define it once, and Apidog attaches it to matching requests automatically.
Global parameters cover four locations, and this is the key to the whole feature:
- Headers (Request Header) for things like
AuthorizationorX-Api-Version. - Cookies (Cookie Information) for session cookies.
- Query (URL Query Parameter) for values like
?api_key=appended to every URL. - Body (Request Body Parameter) for a field every request body should carry.
For the auth-header use case, you want Headers. The other three work the same way if your standard value lives in a cookie, a query string, or a body field instead.
One rule matters before you start: global parameters have lower priority than parameters defined at the endpoint level. If a specific request already sets its own Authorization header, that endpoint-level value wins and the global one steps aside. Think of a global parameter as the default that fills in when an endpoint hasn’t spoken for itself, not a hard override that stamps over everything. That precedence is what makes globals safe to turn on across a large project.
Set a global header on every request
Here’s the core walkthrough. The goal: attach Authorization and X-Api-Version to every endpoint in the project without editing any of them.
Step 1: open Environment Management
Global parameters live in Environment Management, which you open from the top right of the page. This is the entry point for parameters that apply project-wide, and the Apidog documentation describes it as the home for values that ride along with every request. Open it, and you’ll see the sections where you add parameters by location.
Step 2: choose the Headers location
Pick Headers (the Request Header location) since you’re adding an auth header. If your standard value were a cookie, a query param, or a body field, you’d pick Cookies, Query, or Body instead. The mechanics are identical across all four.
Step 3: fill in the parameter details
Each global parameter has a fixed set of properties. Fill them in for your first header:
- Name:
Authorization - Type: the parameter type (string for a header value).
- Default Value:
Bearer {{token}}(more on that{{token}}piece below). - Description: a short note like “Bearer token for all authenticated endpoints.”
A Default field and a required marker (an asterisk *) also appear on required parameters. Add a second row the same way for the version header:
- Name:
X-Api-Version - Type: string
- Default Value:
2024-08-01 - Description: “Pinned API version for every request.”
Step 4: toggle the parameter on
Each parameter has an enable/disable switch on the right side. Flip it on to activate the parameter. That toggle is handy later: if you ever need to silence a global header for a debugging session, you disable it here instead of deleting it and retyping the whole thing.
Step 5: save
Save the configuration. Both headers are now global. Every request in the project will carry Authorization and X-Api-Version unless a specific endpoint overrides one of them.
Step 6: prove it actually went out
Don’t trust that it worked; check. Send any request in the project, then open the Actual Request tab in the response console. That tab shows the request exactly as it was sent, with variables already replaced by their real values. You should see both headers listed there:
GET /v1/orders/8842 HTTP/1.1
Host: api.yourservice.com
Authorization: Bearer sk_live_7f3a9c2e1b8d4056
X-Api-Version: 2024-08-01
If the headers show up in Actual Request, they went out on the wire. This is the single most useful beat in the whole setup, because it turns “I think it’s applied” into “I can see it was applied.”
Keep the secret out of the header: use a variable
Notice the Default Value above was Bearer {{token}}, not Bearer sk_live_7f3a9c2e1b8d4056. That double-brace syntax references a variable instead of hardcoding the raw token into the parameter. The Bearer scheme itself is defined in RFC 6750, and the MDN Authorization header reference covers how servers read it. Apidog’s docs are explicit about the safety angle: for sensitive data like auth tokens and API keys, use environment variables rather than storing the raw value as a plaintext Default Value. A variable is a dynamic placeholder for a value you use across many requests and scripts, and it keeps the secret out of the parameter definition.
Here’s how to set up the token variable:
- Click the environment icon (the
≡icon) at the top right. Note this is a different entry point from Environment Management: the≡icon is where variables live. - Find the Global Variables section.
- Create a variable, for example
tokenwith a value of your bearer secret. - Click Save.
Now your global header value Bearer {{token}} resolves to Bearer <your-real-secret> at send time, and the Actual Request tab confirms the substitution. Hovering over a variable name anywhere shows its current value and scope, which is a fast way to check you referenced the right one.
This pairing is the recommended pattern: the global parameter owns the header slot, and the variable owns the secret. Our deep dive on API client environment and secrets management goes further on how to keep tokens out of anything you might share or commit.
Switch values per environment
Variables get more useful when you have more than one. Real projects hit different servers for Development, Testing, and Production, and each usually wants a different token. Group each set under its own environment, then switch between them with the Environments dropdown next to the ≡ icon (a sample environment might be named Local Mock). Switching an environment points your requests at a different set of servers and swaps in that environment’s variable values. Your global Bearer {{token}} header stays the same; only the resolved secret changes with the environment. If you’re building auth flows on top of this, the concepts in our security schemes guide explain how bearer, API-key, and OAuth definitions map onto real requests.
When you only want the header on one folder
Global parameters hit the whole project. Sometimes that’s too broad. Say only your /admin endpoints need an X-Admin-Scope header, and the rest of the project shouldn’t carry it.
Here’s the honest limitation: Apidog does not have a native “add header” field in folder settings. There’s no folder-level header UI to fill in. What the docs document instead is a workaround using a pre-request script at the folder level, so every request inside that folder inherits the header. The script uses Postman-compatible pm.* scripting:
pm.request.headers.add({ key: 'X-Admin-Scope', value: 'full' });
Add that as a pre-request script on the folder, and every request in the folder picks up the header, while requests outside the folder don’t. It’s a script, not a settings toggle, so treat it as a deliberate fallback for folder-scoped needs rather than the primary path. For the broader scripting model this sits on top of, see our guide to pre-request and post-request scripts in Apidog.
Which lever, and when
You now have three ways to attach a header without editing endpoints. Pick by scope:
- Global parameter (Headers) via Environment Management: the header applies to the whole project. This is your default for a shared auth header or version header.
- Environment variable (
{{token}}): pair it with the global parameter so the header slot is global but the secret is stored safely and swaps per environment. - Folder-level pre-request script (
pm.request.headers.add): the header applies to one folder only. Reach for this when project-wide is too broad.
A couple of things to watch. Check for duplicate parameter names so two global headers don’t collide, and make sure each parameter’s Type matches how it’s used. And remember the precedence rule: an endpoint that sets its own Authorization overrides the global one, which is a feature when one route needs a different token, but a surprise if you forgot that route had its own value. None of these three features carries any plan gating in the docs, so you don’t need a specific tier to use them.
Automate the workflow with the Apidog CLI
Global parameters and environments aren’t just a GUI convenience; they carry into automated runs too. When you build a saved test scenario in Apidog and run it from the command line, the run inherits an environment you pass by id, so the same Bearer {{token}} header and X-Api-Version value that worked in the GUI resolve the same way in CI.
Install the CLI (Node.js v16+) and authenticate:
npm install -g apidog-cli
apidog login --with-token <YOUR_ACCESS_TOKEN>
Then run a saved scenario against a specific environment:
apidog run --access-token $APIDOG_ACCESS_TOKEN -t <scenario_id> -e <env_id> -r cli
The -e flag selects the environment, so the scenario picks up that environment’s variables, including your token. The -t flag is the test scenario id and -r is the reporter (cli, html, or junit). That’s the tie: define the header and variable once, and every scenario run through the CLI carries them. For setup and token details see the Apidog CLI installation guide, and to wire runs into automation, our Apidog CLI in GitHub Actions walkthrough shows the full pipeline.
FAQ
Do global parameters override a header I set on a specific endpoint?
No. Global parameters have lower priority than endpoint-level parameters. If a request defines its own Authorization header, that value wins and the global one is ignored for that request. Globals act as the project default, filling in wherever an endpoint hasn’t set its own value.
Where should I store the actual token so it isn’t sitting in plaintext?
Use an environment or global variable, not a raw Default Value. Set the global header to Bearer {{token}} and keep the real secret in a variable created through the ≡ environment icon. The docs recommend variables or secure methods for sensitive data specifically so the token isn’t stored inline. Our guide to extracting variables with JSONPath covers capturing a token from a login response and reusing it the same way.
How do I confirm the global header was actually sent?
Send any request, then open the Actual Request tab in the response console. It shows the request as it was really sent, with {{token}} and other variables already replaced by their values. If your header appears there, it went out on the wire.
Can I add a default header to just one folder instead of the whole project?
Yes, but not through a settings field, because Apidog has no native folder-header UI. Add a pre-request script on the folder using pm.request.headers.add({ key, value }), and every request in that folder inherits the header while the rest of the project doesn’t.
Do I need a paid plan to use global parameters or environment variables?
The documentation for these features doesn’t list any tier restriction. Global parameters, environment variables, and folder-level pre-request scripts are all documented without a free-versus-paid gate.
Wrapping up
Setting a header on every request is a one-time job in Apidog: define the header as a global parameter under Environment Management, reference the secret as a {{token}} variable so it stays out of plaintext, and confirm it went out with the Actual Request tab. When you need a header on only one folder, the pre-request script fallback covers it. To follow along in your own project, Download Apidog and set up your first global header. It’s free, no credit card required.
