Skip to main content
App secrets authenticate your server’s requests to the Privy API. Each request sends your app ID and an app secret with Basic authentication, along with the privy-app-id header.
Never expose an app secret outside of your backend server. Privy does not store your app secret. Lost app secrets cannot be recovered and must be re-generated.

​
Access levels

When you create an app secret, you choose its access level: Use read-only secrets for services that only need to look up data, such as analytics pipelines, support tools, internal dashboards, and reconciliation jobs. If a read-only secret is exposed, it cannot be used to create wallets, sign transactions, or change your app’s configuration. App secrets created before access levels were introduced have full access.
The access level of an app secret cannot be changed after it is generated. To change access, generate a new secret with the access level you need and delete the old one.

​
Create an app secret

  1. Go to Configuration > App settings > Basics in the Privy Dashboard.
  2. Under API keys, select New secret.
  3. Select Full access or Read-only as the access level.
  4. Select Generate secret, then copy the secret and store it in a secret manager.
Each app can have up to 5 app secrets. Only teammates with the Admin role can create and delete app secrets.

​
Read-only access

​
Supported endpoints

A read-only app secret can call all GET endpoints except the following: A read-only app secret can also call the following POST endpoints, which look up data without changing it: All other requests require a full access secret, including every request that creates, updates, or deletes a resource.

​
Error handling

When a read-only app secret makes a request that requires full access, the API returns a 403 Forbidden error with the code insufficient_app_secret_permissions. These requests do not count toward your app’s rate limits. If your app uses an IP allowlist, Privy checks the allowlist first. A request from an IP address that is not allowlisted receives the IP allowlist’s generic 403 Forbidden error instead.

​
Best practices

  • Enforce least privilege. Give each service the lowest access level it needs. Reserve full access secrets for services that create wallets, send transactions, or manage your app’s configuration.
  • Use one secret per service. Separate secrets let your app rotate or delete credentials for one service without affecting others.
  • Combine with an IP allowlist. An IP allowlist limits where any app secret can be used from.