Rumatadocs
SupportOpen Rumata
Browse documentation

Secrets and integrations

Open MarkdownOpen JSON

Connect external services while keeping credentials out of prompts and frontend code.

8 min readUpdated Sep 6, 2026

Step-by-step guidance.

Before you start

  • An existing service credential with the scope your integration needs.
  • Permission to manage secrets in the target project.

What belongs in a secret?

Store API keys, service passwords, and signing values as protected secrets. Keep them out of public source files, browser bundles, screenshots, and chat prompts. Use clear names so your team can identify each secret without reading its value.

Open Secrets to review each secret’s name, type, and description. Existing values stay hidden. When editing, leave the value empty to keep it unchanged.

Reference capture from the separate Sabai Talk Thai application (September 8, 2026). The system-managed value stays hidden. Workflows refer to the secret by its reference rather than placing its value in documentation.

Add and use a secret

  1. Open Secrets in System Explorer and confirm the intended project.
  2. Use the add control, then enter a descriptive name, choose the appropriate type, and briefly explain the secret’s purpose.
  3. Enter the value only in the secret value field and save it.
  4. Configure the backend workflow or activity to reference the secret through its supported secret selector or configuration.
  5. Run a harmless integration check and inspect a redacted result.
Reference capture from the separate Sabai Talk Thai application (September 8, 2026). Add Secret opens a form. Review the name and value before saving; this empty form was cancelled.

Grant only the access needed

Use Manage access for the secret to review who or what can use it. An integration needing one key should not automatically receive every project secret. Check inherited account-wide permissions as well as local groups.

Replace a credential deliberately

  1. Identify every workflow or activity that uses the credential.
  2. Create a replacement at the service provider using its normal process.
  3. Edit the Rumata secret and enter the replacement value.
  4. Verify an authorized test request works.
  5. Revoke the old provider credential after dependent integrations have switched successfully.

Deleting the secret before updating the integrations that use it can break those integrations. If a key was exposed, treat revocation and replacement as an incident response rather than simply hiding the value in the UI.

Technical reference

Backend-only authentication

HTTP Request nodes support secret-backed authentication headers. Keep credential resolution on the server side. Do not return secret values in workflow output, saved execution payloads, or application error messages.

The factory JWT secret is used to sign authentication tokens. Changing it can affect tokens and dependent authentication flows. Review its specific guidance and consumers before rotating it.