Bring your own key

Bring your own key (BYOK) lets Keiki use a provider account you pay for directly instead of Keiki's shared provider credentials. Save the key as a developer secret, and the matching service uses it when running for that API key. You can bring a key for one service and keep using Keiki's credentials for the others.

Availability and billing

The dashboard offers BYOK on Pro and above. When you save one of the provider secrets below, it checks your plan's BYOK entitlement. If it isn't included, saving is refused with “Using your own provider keys is on Pro and above.” Legacy plans retain access until they migrate.

Usage made with your own provider credential does not spend Keiki platform credits for that service. You pay the provider under your own account's pricing and limits. This does not remove your Keiki subscription or charges for other services still using platform credentials.

Supported provider secrets

Use the exact, case-sensitive name:

For browsing, the secret authenticates an automation runner, not the Browserbase API directly. Configure your runner's HTTPS endpoint as BROWSERBASE_RUNNER_URL as well. An ordinary Browserbase API key alone is not enough.

The Secrets dialog also offers FREESTYLE_API_KEY for agents using the alternative Freestyle sandbox. Match the key to the sandbox provider your agent uses.

Apple Messages for Business channels and people research do not support BYOK. Managed email also does not have a BYOK option. Saving an arbitrary secret does not make an unsupported service use it.

Set a key in the dashboard

1. Open Settings → Secrets in your organization.
2. Choose Add secret. Choose a service to fill in its name, or enter one of the names above yourself.
3. Paste the provider credential into the value field and choose Save secret.

Values are encrypted at rest and cannot be read back. The table shows names and masked values. Use Overwrite to replace a key, or delete it to remove the override. Dashboard changes apply across the organization's active API keys.

These are developer secrets, not personal secrets supplied by individual people in conversations. See Security for encryption and key-handling details.

Set a key through the API

Use your Keiki API key as the bearer token and your provider key as the secret value. The developer API stores the secret for the authenticating API key:

curl -X PUT https://onkeiki.com/api/v1/developer/secrets/OPENROUTER_API_KEY \
  -H "Authorization: Bearer $KEIKI_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"value":"YOUR_OPENROUTER_API_KEY"}'

The response is metadata only:

{"status":"stored","name":"OPENROUTER_API_KEY"}

GET /api/v1/developer/secrets lists names and metadata, never values. Repeat the PUT to rotate a key. Remove it with DELETE /api/v1/developer/secrets/OPENROUTER_API_KEY.

Check the key before relying on it

Saving a secret is not a provider credential test. A nonempty value can be stored even if the provider will reject it. Run the relevant agent action after saving, and check its result and the agent's logs for failures. For example, a browser runner rejection is reported as a runner error with its HTTP status. The dashboard shows secret-save errors in the dialog.

A readable saved key takes precedence over the platform credential. If the provider rejects it, Keiki does not retry that request with the platform key. Overwrite the secret with a valid credential, or delete it to return to the platform credential where one is configured. If no credential is available, the service cannot run. A stored secret that cannot be read or decrypted can fall back to the platform credential; that usage is platform-billed.