For AI agents: the complete documentation index is at https://docs.routebase.dev/llms.txt. Every page is also available as Markdown by appending index.md to its URL or by sending Accept: text/markdown.
Projects

Variables

Variables keep configuration out of your requests. Instead of hard-coding URLs, tokens and IDs, you reference {{variableName}} and let the active environment supply the value. The same test or monitor therefore runs against dev, staging and production unchanged.

Scopes and resolution order

Variables exist in three scopes:

Scope Where it's managed Who sees it
Organization Settings → Variables (Organization Variables) Available across all projects in your organization.
Project (environment) The Variables tab of each environment Shared with everyone in the project, and each environment has its own set.
Personal The My Variables tab of each environment Only you, which suits personal tokens and local overrides.

On key conflicts, the more specific scope wins, so Personal beats Project, which beats Organization. Keys are compared case-insensitively.

The Resolved tab of an environment shows the final merged set. Each variable appears with its value, with secrets masked, a Secret or Plain type badge, and a Source badge reading Org, Project or Personal to tell you which scope supplied it.

The Resolved tab showing merged variables with organization, project and personal scope badges and an overridden value

Organization variables also appear as read-only rows inside each environment's Variables tab, marked Org. Double-click one to override it at the environment level. The key stays fixed, you supply the environment-specific value, and the row gets an Override badge.

Editing variables

Open an environment from the Projects page sidebar, or use Edit Variables in the header's environment switcher. The variable table edits inline:

  • Add variable, the + button, adds a row, and double-clicking any row edits it. Each variable has a Key, a Value, a Secret checkbox and an optional Description.
  • Keys must use letters, digits and underscores, and must not start with a digit. Duplicate keys are flagged and not saved.
  • The table is keyboard-friendly. Enter commits, Tab moves through fields and onto the next row, and the up and down arrows jump between rows. Tabbing past the last row starts a new one.
  • Drag the grip handle to reorder rows.
  • Right-click a row for Edit, Duplicate and Delete. Duplicating a secret leaves its value behind.
  • Changes auto-save, and a brief "Saving..." indicator appears next to the heading.
The environment variables table with a row in inline edit mode

Secrets

Mark a variable as Secret to store it encrypted and mask it as •••••••• everywhere, which covers tables, previews and exports. To see a secret's value, click the eye icon labelled Reveal value while editing, and the reveal fetches the decrypted value on demand. The audit log records reveals and exports, and it records secrets being created, changed or deleted. It also records a variable losing its Secret flag under the label Unsecured, because from then on the value is served unmasked. Saving other variables never counts as a change to a secret you did not touch.

If a variable's key looks sensitive, such as one containing "token" or "password", but is not marked secret, a dismissible banner suggests marking it. It reads "You have variables that may contain sensitive data … Consider marking them as secrets for encryption and masking."

Secret values are deliberately never copied when you duplicate a variable, copy variables into a new environment, or copy an auth configuration. Only the structure travels, so you re-enter the secret at the target.

Templates

The Apply template button adds a predefined variable set, skipping keys you already have:

Template Variables
REST API API_BASE_URL, API_KEY as a secret, and API_TIMEOUT
Authentication (OAuth) AUTH_URL, CLIENT_ID, CLIENT_SECRET as a secret, AUTH_AUDIENCE, BEARER_TOKEN as a secret, and REDIRECT_URI
Database DB_HOST, DB_PORT, DB_NAME, DB_USER, and DB_PASSWORD as a secret

Importing variables

The import button in the table toolbar opens a three-step dialog:

  1. Under Import Variables, choose the format, either .env or JSON, and paste the content. In .env format, a # comment line above a variable becomes its description.
  2. Under Preview Import, review the parsed variables. Keys that look like secrets are auto-detected, marked auto, and will be encrypted, and you check or uncheck the Secret box per variable. Then choose a Duplicate strategy of Skip duplicates, Overwrite existing or Error on duplicates.
  3. Import Complete summarizes the created, updated, skipped and errored variables.

Exporting variables

The export button downloads the environment's resolved variable set as a file:

  • Format offers .env, which is standard dotenv, or JSON, which is structured and carries metadata.
  • Include secret values is off by default, so secrets are exported masked. Turning it on decrypts secrets into the file, and the dialog notes that this requires admin permissions. Every exported secret is recorded in the audit log, so treat such files carefully.

Using variables

Reference any resolved variable as {{variableName}}, in double curly braces:

  • Test requests take them in the URL, headers or body, as in {{baseUrl}}/orders or Authorization: Bearer {{API_TOKEN}}. The request editor's Variables tab lists every available variable, shows which ones the request uses, previews the resolved URL with secrets masked, and warns about unresolved placeholders before you run.
  • Auth configuration accepts {{VARIABLE_NAME}} in every field, with autocomplete from the environment's resolved variables. See Project Auth.
  • Monitors support the same placeholders in URLs, headers and request bodies, resolved from the monitor's environment. See Monitors.

One variable is built in. {{baseUrl}} always resolves to the active environment's Base URL, unless you define your own variable with that key. Requests that use an unresolved variable fail with a clear "unresolved variables" error rather than silently sending the placeholder.

For dynamic values inside test scenarios (fixtures, captures, generated data), see Test Data.

Permissions

  • Environment variables at project scope need projects:write for editing, importing and reordering, which Admins and Owners have. Members can view them and use them in requests.
  • Organization variables need org:manage-governance to manage, which Admins and Owners have.
  • Personal variables are managed by every member for themselves.