Variables

#Overview

A variable is a value your organization stores once and reuses when configuring other resources — a token, a credential, or a configuration setting such as an API key or an environment variable. Instead of pasting the same value into every place it is needed, you define it once as a variable and reference it wherever it applies.

Two characteristics make variables worth setting up early:

• They are centralized. One stored value serves every configuration that needs it, so integrations stay consistent and there is a single place to change the value when it changes.
• They can be shared without being exposed. Each variable has a type — text or secret — which determines how the value is handled. The secret type is for values that must be protected, so credentials can be shared with the people and configurations that need them without the underlying secret being handed around.

Variables are referenced when configuring MCP Connections, Tool Definitions, and Webhooks — the parts of Opal that reach out to external systems. That makes them the quiet foundation under most integrations: the connector that fetches live data, the tool that calls an API, and the webhook that pushes an event to another system can all draw on the same stored credential.

Like other resources in Opal, variables sit inside the platform's cross-cutting layer of governance. They carry permissions, so access is controlled at the resource level; version tracking, so changes to a value are recorded over time; and a Linked Resources panel, so you can see exactly where a value is being used before you change it.

A typical example: an organization stores one external service's API key as a secret variable with the key service_api_key, and every connection, tool, and webhook that talks to that service references it rather than holding a copy of the key.

#Key Capabilities

• Store tokens, credentials, and configuration values in one place. API keys, environment variables, and other settings live as variables rather than being re-entered in each configuration.
• Choose how a value is handled. Set a variable's type to text or secret depending on whether the value needs protecting.
• Share values securely with organization members. Members can use a variable in their configurations without the sensitive value being exposed broadly.
• Reference stored values when configuring other resources. Variables can be referenced when configuring MCP Connections, Tool Definitions, and Webhooks.
• See where a variable is used. The Linked Resources panel lists the resources that reference the variable.
• Track changes over time. Version tracking records how a value has changed.
• Control who can access and manage each variable. Permissions are applied per variable, in the same way as for other resources.

#How it Works

Variables are managed in the Variables section. That is where they are created, viewed, and maintained — one place for the values the rest of the organization's configuration draws on.

What a variable is made of. Creating a variable means supplying four things:

Defining and using a variable, in order.

1. Open the Variables section.
2. Create a variable and give it a key — the name you will reference it by.
3. Add a description if the purpose of the value is not obvious from the key.
4. Set the type: text for ordinary configuration values, secret for credentials and anything else that must be protected.
5. Enter the value.
6. Reference the variable when configuring an MCP Connection, a Tool Definition, or a Webhook, instead of entering the raw value there.

Where variables get referenced. The three places variables are used correspond to the three ways Opal reaches an external system:

• MCP Connections — connectors are built on the Model Context Protocol, and an MCP Server holds a service's URL and its authentication type (None, Bearer Token, or OAuth). Variables supply the credentials and configuration values those connections require.
• Tool Definitions — a tool definition describes a single callable action, and referencing a variable lets the tools created from it use stored tokens and configuration values.
• Webhooks — variables can be referenced when configuring webhooks.

Linked Resources is what makes a change safe to make. Because one variable can be referenced in many configurations, changing its value has reach. Opening the variable's Linked Resources panel shows the resources that reference it, so the impact of a change is visible before it is made rather than discovered afterwards.

A worked example — rotating an API key. An administrator connects several of the organization's agents and integrations to an external service that requires an API key. Rather than pasting the key into each MCP Connection, Tool Definition, and Webhook, she creates a variable with the key service_api_key, sets its type to secret, and enters the key as the value. Team members reference the variable when they configure those resources, so nobody handles the raw key.

Months later the key has to be rotated. She opens the variable's Linked Resources panel to confirm everywhere it is used, updates the value in one place, and relies on version tracking to preserve a record of the change. What would have been a hunt through many configurations becomes a single edit.

Governance applies to variables as it does to other resources. Permissions govern who can view or manage each variable, and version tracking records how values change. The controls available differ from one resource type to another, so check the variable itself for what applies.

#Additional Notes

• Choose the type deliberately. The type is what tells Opal how to handle a value. Text is appropriate for configuration values that are not sensitive; secret is for values that must be protected. This documentation does not describe how secret values are displayed or whether they can be read back — check the Variables section for the behavior in your organization.
• A variable is a shared value, not a personal one. Variables exist so credentials and configuration values can be shared across the organization under permissions, rather than being kept by individuals.
• Referencing a variable does not grant access to the connected system. MCP Connections are created per user and carry that individual's own permissions in the connected service. A variable supplies a stored value to a configuration; what someone can reach in the external system is determined by that system and by how the connection was set up. See Connectors.
• Plan a rotation before you make it. The Linked Resources panel exists for this: check it first, then change the value once. Opal does not, in this documentation, describe automatic rotation or expiry of stored values.
• Some details are not covered here. The exact syntax or control used to reference a variable in each configuration field, naming rules for keys, limits on how many variables an organization can hold, and how version tracking presents past values are not documented here. Check the Variables section for what applies to your organization.
• Short definitions of the terms used here are in one place: Glossary.

#Related Features

• Connectors — How Opal links to external tools and systems over the Model Context Protocol; variables supply the credentials and configuration values MCP Connections require. Connectors
• Tools — Tool definitions describe a single callable action, and can reference variables so tools use stored tokens and configuration values. Tools
• Webhooks — How an organization subscribes to platform events and sends them to external systems; webhook configuration can reference variables. Webhooks
• Resource Tags — Organization-defined labels for classifying resources and filtering to everything that carries a tag. Resource Tags
• Platform Configuration — The cluster this page belongs to: the organization-wide configuration options, including resource tags, variables, and webhooks. Platform Configuration
• Access & Permissions — The full access model behind plans, role permissions, and per-resource permissions. Access & Permissions
• Glossary — Short definitions of the terms used on this page. Glossary