Authentication

Storentia has two independent auth paths, for two different callers. Mixing them up is the most common integration mistake.

• Account auth — a human signing into the dashboard to manage their own stores. OTP login, JWT bearer tokens.
• App auth — a server, SDK, or App Registry integration acting on behalf of a store. OAuth2 client credentials, or a store-scoped public token.

Call POST /v1/auth/login with an email to send a 6-digit OTP, then POST /v1/auth/login/verify with the email and OTP to receive an access/refresh token pair. Google and GitHub OAuth login are also available as shortcuts to the same token pair.

Pass the access token as a Bearer token on every authenticated request:

Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

Tokens can be revoked server-side (logout, logout-all, session revocation) — a revoked token is checked against a blacklist on every request, so it stops working immediately rather than waiting for expiry.

Integrations authenticate as an OAuth app registered under a store, not as a person. Register an app to get a client_id / client_secret pair, then exchange it for an access token:

curl https://apis.storentia.com/v1/auth/oauth/token \  -H "Content-Type: application/json" \  -d '{    "grant_type": "client_credentials",    "client_id": "sca_9f2c1a8b3e7d4f60",    "client_secret": "scs_5b6a7c8d9e0f1a2b"  }'

The official SDKs do this exchange for you — pass clientId / clientSecret to the constructor and the SDK fetches and refreshes tokens automatically.

For read-only, customer-facing use (a storefront frontend calling GraphQL directly from the browser) generate a store public token instead of using an OAuth app secret — it carries less privilege and is safe to scope narrowly. See Generate a public API token.

• Never expose an OAuth app client_secret in browser code.
• Use a public token, not a client secret, for anything client-side.
• Rotate OAuth app secrets and public tokens you no longer recognize.
• Revoke sessions from any device you no longer trust.