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 Nov 1, 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. Bind the secret to the backend service’s intended development or production environment, or select it in the workflow/activity configuration that needs it.
  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 backend service, workflow, activity or connector 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. Restart the development process or redeploy dependent services when required, then verify an authorized test request without logging the value.
  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.