The api_secret auth method is designed for server-to-server integrations where your backend controls the authentication flow. Instead of relying on a third-party auth provider, your backend authenticates directly with the Privacy Boost API using a client_id and client_secret pair — similar to OAuth 2.0 client credentials.This is the right choice when:
Your backend already manages user authentication and you don’t use a third-party auth provider
You need programmatic access (scripts, bots, automated systems)
You want full control over who can authenticate without depending on an external JWKS endpoint
Contact the Privacy Boost team to configure your app with the api_secret auth method. You’ll receive:
App ID — Your application identifier (e.g., app_abc123xyz)
Client ID — A unique identifier for your credentials (e.g., pb_cred_abc123xyz...)
Client Secret — A secret key for authenticating requests
Store your client_secret securely. It should never be exposed in client-side code, committed to version control, or logged. Use environment variables or a secrets manager.
# Environment variables (development)export PB_CLIENT_ID="pb_cred_abc123xyz..."export PB_CLIENT_SECRET="your-secret-here"# Or use a secrets manager in production (AWS Secrets Manager, HashiCorp Vault, etc.)
If this runs in a browser, set keyVault.mode to local before passing a tokenProvider; the default browser iframe vault intentionally does not accept host-page token callbacks.
import { PrivacyBoost } from '@sunnyside-io/privacy-boost';const sdk = new PrivacyBoost({ serverUrl: 'https://optimism.sepolia.privacyboost.io', appId: 'app_abc123xyz', keyVault: { mode: 'local' },});
Credentials can optionally have an expiry date. If your credential expires, requests will fail with invalid_credentials. Request a new credential before the current one expires.
Never expose credentials in client-side code. The client_id and client_secret must only exist on your backend.
Use environment variables or a secrets manager. Don’t hardcode credentials.
Rotate credentials periodically. Treat them like passwords.
Authenticate your own users first. Your backend endpoint should verify the caller’s identity (session token, JWT, etc.) before forwarding to Privacy Boost. Otherwise, anyone who discovers your endpoint can authenticate.
Use HTTPS only. All communication between your backend and Privacy Boost must be over HTTPS.