> ## Documentation Index
> Fetch the complete documentation index at: https://docs.frayme.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Credentials & secrets

> Where API keys live, how they rotate, and the difference between resold and BYO provisioning.

## Resold vs BYO

Frayme draws a hard line between the two provisioning models:

<Tabs>
  <Tab title="Resold">
    * The UI hides credential fields entirely and shows the **Reselling agreement** notice.
    * Credentials are stored in the Frayme platform secret store (Vault / AWS Secrets Manager in production), never exposed to client tenants.
    * Billing flows through Frayme; clients see consumption metrics, not vendor invoices.
  </Tab>

  <Tab title="BYO">
    * Client provides the API key + endpoint at provider creation.
    * Stored encrypted-at-rest, per-tenant.
    * Workflow nodes resolve the credential by `provider_id`; the credential value itself never appears in `workflow_executions.json` or audit logs (only a `credential_id` reference).
  </Tab>
</Tabs>

## Rotation

<Steps>
  <Step title="Open the provider's Settings">
    Gear icon in the Data Sources table.
  </Step>

  <Step title="Paste the new API key">
    The input is masked. The placeholder reads "Paste new key to rotate". Leaving the field blank keeps the current key.
  </Step>

  <Step title="Save">
    The next outgoing call uses the new key. In-flight calls continue with the old key for graceful drain.
  </Step>

  <Step title="Test">
    Click `Test` to confirm the new key works before disabling the old one upstream.
  </Step>
</Steps>

## Reveal vs rotate

The `Reveal` toggle on the API key field shows the current key in plaintext. Every reveal is **audit-logged** (`actor`, `provider_id`, `action: reveal`, `ts`). Production deployments can require an additional confirmation step (re-MFA) before reveal.

## Workflow-level secrets

Custom API nodes can also reference `{{secrets.<name>}}` variables that aren't tied to a Data Source — for example `{{secrets.sumsub_app_token}}` and `{{secrets.sumsub_signature}}` used by Sumsub admin endpoints (override review answer, generate scoped access token).

These are stored on the workflow's `connections` map and managed under [Workflows → Connections & secrets](/workflows/connections-secrets).

## What never gets logged

<Check>
  The credential value itself — only the `credential_id` reference.
</Check>

<Check>
  Sumsub `X-App-Access-Sig` request signatures — replay-resistant by design but still treated as sensitive.
</Check>

<Check>
  Bearer tokens in `Authorization` headers — masked to `Bearer ******` in audit entries.
</Check>