Header profiles
Reusable HTTP header sets for the runner — personal, workspace, and shared.
Header profiles are named bundles of HTTP headers (and their values) you can attach to any runner request. Use them so you don’t paste Authorization: Bearer …, X-Request-Id: …, or X-Tenant: … every time.
Three scopes
| Scope | Visibility | Edit by |
|---|---|---|
| Personal | Just you | You |
| Workspace | All workspace members | Owners + Editors |
| Shared | Available across all your workspaces | Superadmin |
Use Personal for your own dev tokens; Workspace for shared service accounts; Shared is platform-managed and rarely something you create.
Creating a profile
From the runner toolbar, click Profiles → New profile. For each entry:
- Key — header name (e.g.
Authorization). - Value — header value. Reference workspace credentials with
{{credentials.scheme_name}}so the actual token never lives in the profile. - Optional: a short description.
Profiles auto-save as you type.
Stacking
You can stack multiple profiles on a single request. The stack rule: lower in the stack overrides higher for the same header key. The runner shows the resolved final headers next to the request preview.
A workspace default stack can be set in Workspace Settings → Header profiles so every member starts with the same baseline.
When to use a profile vs a credential
| Use a credential when… | Use a profile when… |
|---|---|
| The value is referenced by an OpenAPI security scheme | The header isn’t part of OpenAPI security |
It maps cleanly to apiKey / http / oauth2 schemes | It’s an arbitrary custom header |
| You want it auto-applied to every operation that requires the scheme | You want explicit, per-request control |
Credentials are the “right” home for OAuth / API keys — see Concepts → Roles & credentials.
Copying
Use Copy profile in the profile menu to clone a profile across workspaces — useful when you’ve configured one and want to seed others.