Skip to main content

Troubleshoot secrets

Check scope, credential, sensitivity level, and value shape in that order. This sequence isolates most secret failures quickly.

Start with five checks​

  1. Confirm the organization and site selected in Console.
  2. Confirm the scope by location: site Secrets, or Operate → Secrets inside the intended app.
  3. Confirm the intended account is signed in.
  4. Confirm the secret type's sensitivity level allows the caller to read the value.
  5. Confirm the value satisfies the secret type's JSON schema.

Match the symptom​

SymptomCheckNext action
401 reading a secretSession or runtime credential; the type's sensitivity levelSign in again in Console, or refresh the runtime credential
403 reading a secretCaller type against the sensitivity levelA site user cannot read sensitive values; use an API key or a cloud user
Secret is absent from ConsoleSelected site/app and exact keyOpen site Secrets for site scope or app Operate → Secrets for app scope, then use Search secrets...
Validation error on saveValues against the selected secret type schemaReopen Edit Secret, correct the highlighted configuration field, and choose Save Changes
Invalid keyKey length and Console input rulesKeep the key within 255 characters; Console accepts letters, numbers, _, or - and does not accept .
Duplicate-key conflictKey within the selected site/app locationSearch for the existing key and use Edit instead of Create Secret
Tagged create failsEvery selected tagThe secret may already exist because the backend saves before resolving tags. Search the same key and scope before retrying, then edit it after fixing tags
Update unexpectedly changes tags or scopeFull update payloadUse Edit Secret from the same site/app page; Console resends tags and the app slug for app scope
Secret type will not deleteSecrets that reference the type, and the type classificationRemove referencing secrets first; a system type cannot be deleted
Cannot change sensitivity levelThe update bodyThe level is immutable; create a new type with the intended level
App value not returnedThe app slug and resolution orderAn app secret overrides a site secret only when the request supplies the app slug. Python substitutes its configured app_slug when app is omitted
Recently changed access still returns a cached resultSite, app, key, and cache TTLThe current resolved-value cache does not include caller identity; do not use a repeated read as proof of caller-isolated authorization state
5xx responseRequest identifier, UTC time, route, and scopeCapture a minimal redacted request before contacting TaruviBase support

Confirm resolution​

When a read returns a value you did not expect:

  1. Open site Secrets and search the key to inspect the site value.
  2. Open the app's Operate → Secrets page and search the key to inspect the app-scoped entry. That list deliberately excludes inherited site entries.
  3. Runtime SDK reads with an app slug still use app-over-site fallback even though the Console app list shows app scope only.

Check a write​

  1. Open site Settings → Secret Types and inspect the type's schema.
  2. Confirm the value fields and types satisfy the schema.
  3. Confirm the key is within 255 characters, satisfies the Console input rules, and is unique within its scope.
  4. Reopen Edit Secret from the same site/app page; keep every required tag and configuration field.
  5. Choose Save Changes, then reopen the secret to verify it.

Confirm the fix​

After applying a change, return to the same Console site/app location, refresh, and confirm the expected result:

  • A read returns 200 with the expected value, or 404 if you intended a deletion.
  • A created secret appears after Create Secret succeeds.
  • An edited secret shows the new value after Save Changes succeeds.
  • A credential or site-access fix returns 200/201 for the intended caller, while an unauthenticated or sensitivity-denied caller still receives 401/403.

If the same error recurs with a minimal request, capture the diagnostics below and contact TaruviBase support.

Share safe diagnostics​

Keep the HTTP status, the error body, the UTC time, the site hostname, and the app slug. If a key name is sensitive, hash the key locally and share the digest instead of the raw name. Do not attach any secret value, credential, token, or raw customer record.