Properties and secrets are named values that any service in a library can use from Liquid-enabled settings such as API URLs, payloads and email variables. Each key has separate QA and Production values.

Open the library and select Properties & secrets. The side navigation separates QA properties, QA secrets, Production properties and Production secrets.

Choose the correct value type

If a value would create harm when copied into a screenshot, ticket or log, treat it as a secret. A secret ID is not itself secret and should describe purpose without revealing the value.

Understand keys and environments

Keys are created, renamed or deleted from the QA side first. The Production screen then accepts a Production value for each key already defined in QA. This keeps the set of references consistent while allowing different values.

flowchart LR
  A[Define key in QA] --> B[Enter QA value]
  A --> C[Enter Production value for same key]
  B --> D[Apply QA settings]
  C --> E[Apply Production settings]
  D --> F[QA Liquid context]
  E --> G[Production Liquid context]

Deleting or renaming a QA key can break every service that references it, including Production. Search the library’s service definitions and documentation before changing a key.

Reference values in Liquid

Use these namespaces:

{{ library.properties.ordersBaseUrl }}
{{ library.secrets.ordersApiToken }}

The Data inspector in Prototype and QA shows the keys available to a Liquid template. It must not reveal a secret’s stored value.

Choose IDs that are stable, readable and safe for dot notation. Use a consistent lower-camel-case convention such as ordersBaseUrl or ordersApiToken. Do not encode an environment in the ID: the environment-specific value supplies that distinction.

Add and apply a property

1. Open QA environment properties.
2. Add an ID and the non-sensitive QA value.
3. Select Apply to QA environment.
4. Test a dependent service in QA.
5. Open Production environment properties and enter the corresponding live value.
6. Apply to Production under the normal approval process.

Properties are visible to builders, so do not use them as a convenient way to avoid secret handling.

Add and apply a secret

1. Open QA environment secrets.
2. Add the stable ID and paste the QA credential directly from the approved source.
3. Apply to QA and test the dependent integration.
4. Open Production environment secrets and enter the separate live credential.
5. Apply to Production and run a controlled smoke test.
6. Remove the credential from the clipboard and any temporary approved transfer mechanism.

Because the value is not displayed again, the source secret manager remains the system of record. If the stored value is uncertain, rotate it rather than attempting to recover it.

Rotate a value without breaking services

Keep the key ID stable. Change the QA value, apply it and test all dependent journeys. Then update and apply Production during the agreed change window. Revoke the old credential at the provider after the new value is proven.

For a property URL change, test request paths, redirects, certificates and error handling. For a secret, test both success and an expected permission failure so that over-broad access is not mistaken for success.

Troubleshoot an unchanged or missing value

Check that:

• the key spelling and capitalisation match the Liquid reference;
• the value was applied to the environment, not merely entered in the Builder;
• the service is being tested in the intended environment;
• a service-level setting is not overriding the library value;
• the external credential is active and has the required permissions;
• a cached or already-running action has been retried after the environment update.

Never print secret values into user-visible content or diagnostic logs to troubleshoot them.

Related guides

• Write Liquid templates
• Library integrations and data
• API actions
• Library authentication settings