Secrets and Variables

Secrets and Variables are named key-value pairs you store once and reference from any connector. A Secret holds a sensitive value — an API key, token, or password — and is masked in the UI. A Variable holds a non-sensitive, plain-text value — a base URL, environment ID, or instance ID — and stays visible so you can see exactly what a connector uses.

Navigate to Integrations → Developer Studio → Secrets and Variables to create, edit, and delete both. To add one, select Add New, choose Secret or Variable, enter a Name and Value, and save.

Choosing between a Secret and a Variable

Choose the type when you add a value. The choice controls how the value is shown and where it can be used.

	Secret	Variable
Use it for	Sensitive credentials — API keys, tokens, passwords	Non-sensitive config — base URLs, environment IDs, instance IDs
Shown in the UI	Masked	Visible in full
Reference with	get_secret('name')	get_variable('name')
Allowed in the connector URL	No	Yes
Available in headers, query parameters, and authentication	Yes	Yes

Variables are visible — never store credentials in them

A Variable's value is plain text and shown in full in the UI. Use Variables only for non-sensitive configuration. For any credential — an API key, token, or password — always use a Secret.

Both are scoped to your community and resolved on the server when a connector executes, so a Variable used in a URL is applied server-side and cannot be tampered with by the browser.

Secrets

Secrets store sensitive values that must never be exposed. Their values are encrypted, masked in the UI — only the first character is shown — and never returned to the browser.

Referencing secrets in connectors

Use the get_secret() function in a template expression to reference a stored secret:

{{ get_secret('secret_name') }}

The expression is replaced with the actual secret value when the connector executes. The value is resolved on the server and never exposed to the browser.

Where get_secret() is available

Field	Available	Why
Authentication config	Yes	Auth values are used only in outgoing requests
Headers	Yes	Request headers are server-side only
Query Parameters	Yes	Request params are server-side only
URL template	No	Secrets stripped to prevent URLs with embedded tokens
Request payload	No	Payload forwarded to upstream API
Response transform	No	Response returned to browser, secrets excluded for safety

Key principle: Secrets resolve only in fields that control the outgoing request to the external API — authentication, headers, and query parameters. They do not resolve in fields that may leak data (URL, request bodies, response bodies) to prevent accidental exposure of credentials.

Security note on URLs: Never embed {{ get_secret('...') }} in the URL template. Secrets are removed before the URL is built, so the reference is left unresolved and the connector fails to execute — and any token placed in a URL would be logged and could appear in browser history. Use the authentication config, headers, or query parameters instead. If you need a non-sensitive value in the URL — such as a per-environment host — use a Variable.

To send a Bearer token, use the Authentication config or a custom Header — not the URL:

{
  "type": "api_key",
  "config": {
    "key": "Authorization",
    "value": "Bearer {{ get_secret('my_token') }}",
    "in": "header"
  }
}

This keeps the token out of URLs, logs, and browser history.

Variables

Variables store non-sensitive, reusable configuration values — base URLs, environment identifiers, instance IDs. Their values stay visible in the UI, so you can confirm exactly what a connector will call.

Variables make connectors environment-aware. Store a value once under a descriptive name — such as salesforce_instance_url or api_environment — then reference that name from a connector instead of hardcoding the value. A community used for development can point at a sandbox host while production points at a live host, by changing one Variable rather than the connector.

Referencing variables in connectors

Use the get_variable() function in a template expression:

{{ get_variable('variable_name') }}

Unlike secrets, variables also resolve inside the URL field, so you can parameterize a connector's host or path per environment. Store the full base URL as the variable's value — for example, set salesforce_instance_url to https://acme.my.salesforce.com — then build the rest of the path around it:

{{ get_variable('salesforce_instance_url') }}/services/data/v59.0/query

The value is resolved on the server when the connector executes.

Where get_variable() is available

In a standard connector, get_variable() resolves everywhere get_secret() does — authentication, headers, and query parameters — and additionally in the URL template. It does not resolve in a standard connector's request payload or response transformation templates.

Field	Available	Why
Authentication config	Yes	Resolved server-side in outgoing requests
Headers	Yes	Request headers are server-side only
Query Parameters	Yes	Request params are server-side only
URL template	Yes	Variables are non-sensitive, so they are kept when the URL is built
Request payload	No	Not available in a standard connector's request template
Response transform	No	Not available in a standard connector's response template

In composite connector steps, get_variable() is available in every step template — including the request body and response body — because all step templates share one context. See Composite Connector Reference.

Naming rules

Secret and variable names must be valid identifiers — letters, numbers, and underscores only. Names are case-sensitive.

Valid names:

• salesforce_instance_url
• api_environment
• oauth_client_id
• weather_api_key

Invalid names (rejected on save):

• instance-url (contains hyphen)
• api key (contains space)
• 123env (starts with number)
• api@key (contains special character)

Use descriptive names that include the service and purpose: salesforce_instance_url, helpdesk_subdomain, stripe_webhook_secret.

A name cannot be used for both a Secret and a Variable in the same community — each name is unique across both.

Error handling

Value not found

If you reference a secret or variable that does not exist — or misspell its name — get_secret() and get_variable() preserve the original template expression literally in the rendered output. That literal string is then used in the request: a missing variable in a URL causes the URL to fail validation, and a missing secret in a header is sent to the external API, which typically rejects the request (401 Unauthorized or 403 Forbidden).

How to diagnose:

1. Use Test Connection — run a test in the connector editor and inspect the X-Debug-Request response header. If a field contains the raw get_secret('...') or get_variable('...') text instead of a resolved value, the name did not resolve. See Testing & Debugging.
2. Verify the name — open Integrations → Developer Studio → Secrets and Variables and confirm the entry exists with exactly the name you used. Names are case-sensitive.
3. Check for typos — compare the name in get_secret('name') or get_variable('name') with the Name column character-by-character.

Validation errors

Error	Cause
Invalid name	Name contains hyphens, spaces, or special characters. See Naming rules.
Empty value	Values cannot be empty.
Duplicate name	An entry with this name already exists. Edit the existing entry or choose a different name.

Troubleshooting

Secret value seems wrong — The masked display only shows the first character. Edit the secret and re-enter the value to confirm it is correct.

Credentials stopped working — Some API keys and tokens expire. Edit the secret to update with fresh credentials, then re-test the connector.

Changing a Secret to a Variable (or the reverse) — The type is set when you create an entry and cannot be changed afterward. Delete the entry and add it again with the type you want.

Template formatting — Use single quotes: get_variable('name'), not get_variable("name"). Avoid extra spaces: get_variable('api_environment'), not get_variable( 'api_environment' ).

Next Steps

• Authentication — Use secrets in API Key, OAuth, and JWT authentication
• Template Variables — Full reference of variables and functions available in templates
• Testing & Debugging — Verify secrets and variables resolve correctly