Secrets and credentials: where API keys live and how to rotate them

Arino One stores every API key and credential in its own database, in a table called \app_secrets\, and resolves each one by checking that database first before ever falling back to a server environment variable. You manage them from Settings → API keys & secrets — a page restricted to administrators, where every change additionally requires re-entering your password.

What lives here

The credentials screen covers every external integration the app can use beyond the Infobip connection wizard itself:

Some of these are optional — a smaller instance running only WhatsApp messaging on the managed AI option may never need to touch the ElevenLabs, Anthropic, OpenAI or Stripe fields at all.

Where a value actually resolves from

Every credential lookup in the app follows the same order:

1. Database first — check app_secrets for a row with that key. If it has a non-empty value, use it.
2. Environment fallback — if the database has no value, fall back to the corresponding environment variable on the deployment.
3. Bring-your-own fallback (Infobip only) — if the managed INFOBIP_API_KEY resolves to nothing, the resolver checks the separate bring-your-own key used by remix/self-serve instances before giving up.

The practical implication: a value you save through Settings always wins over whatever was set at the infrastructure level, which prevents a stale platform default from silently overriding a key you've deliberately configured. It also means that if a message-sending feature suddenly breaks after a database change, checking whether an app_secrets row was accidentally cleared should be your first troubleshooting step, ahead of checking environment configuration.

Who can see and change credentials

Access is deliberately narrow:

• The API keys & secrets page is gated to administrators only; non-admin roles cannot open it at all.
• Every set or clear action requires confirming your own admin password in a re-authentication dialog before it takes effect — there is no bulk edit or unattended change path.
• Saved values are never redisplayed. The interface shows a masked state once a key is saved; there is no "reveal" action, so retrieving a previously saved value is not possible from the UI — if you've lost the original key, you must generate a new one at the provider and save that instead.
• Where an integration supports it (currently ElevenLabs), a connection test runs against the live value so you can confirm it works before depending on it, without needing to see the key itself.

Rotating a credential safely

Because the database value always takes priority once saved, rotation is safe to do without downtime:

1. Generate the replacement credential in the provider's own dashboard (Infobip, Anthropic, OpenAI, Stripe, or Cloudflare).
2. Paste it into the corresponding field on Settings → API keys & secrets and confirm with your password.
3. Run the built-in test if one exists, or trigger the dependent feature (send a test message, generate a voice note, place a test call) to confirm the new value works.
4. Only once the new value is confirmed working, revoke the old credential at the provider. Revoking first, before confirming the new one works, risks an outage in whatever the credential powers.

Rotate immediately, out of cycle, if a key may have been exposed — pasted into a support ticket, visible in a screen share, or held by someone who has left the organisation. Routine rotation on a fixed schedule (many teams use 90 days for anything touching billing) is good hygiene even without a known exposure.

What Arino never sees

Arino Link's outbound connection — covered in full in Arino Link and the Command Inbox — never transmits credentials of any kind, in any of its three traffic tiers. Heartbeats report only coarse booleans such as whether Infobip is connected, never the key itself. This is enforced by an automated test in the codebase, not merely stated as policy, so a credential leaving your instance toward Arino is not a configuration risk you need to manage — it structurally cannot happen through that channel.

Handling credentials safely day to day

• Never paste a live credential into a chat window, support ticket, or screenshot — redact it first if you need to show context.
• Treat any credential that has been shared outside the settings page as compromised and rotate it, even if the sharing was accidental or internal.
• Keep the list of who holds admin access current — see the user roles reference — since admin access is what gates who can view the settings page and change these values.
• For anything billing-adjacent, such as the Stripe keys, check audit and evidence for how changes here are logged for review.

Steps at a glance

1. Open API keys & secretsGo to Settings → API keys & secrets. This page is only visible to administrators.
2. Locate the credentialFind the key you need to change — Infobip API key, ElevenLabs, Anthropic, OpenAI, Cloudflare TURN, or Stripe — each with a short label and help text.
3. Enter the new valuePaste the replacement key into the field. Existing values are masked and never redisplayed in full, so you cannot recover a lost key from this screen — only overwrite or clear it.
4. Re-authenticate to confirmConfirm the change with your admin password in the re-authentication dialog. This step is required for every set or clear action, with no exceptions.
5. Test the connection where availableFor credentials with a built-in test, such as ElevenLabs, run it immediately after saving to confirm the new key is valid before relying on it.
6. Retire the old key at the providerOnce the new key is confirmed working, revoke the old one in the provider's own dashboard (Infobip, Anthropic, OpenAI, Stripe, Cloudflare) so a leaked or former key can no longer be used.

Frequently asked