OAuth apps & public tokens

Two credential types let non-humans call Storentia's APIs on behalf of a store: OAuth apps and public tokens. Picking the right one matters — one is a secret, one is safe to expose.

An OAuth app is registered under a store and gets a client_id / client_secret pair — this is what the storentiajs/storenntiapy SDKs expect. Treat the secret like a password: server-side only.

curl https://apis.storentia.com/v1/user/stores/oauth/apps \  -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIs..." \  -H "Content-Type: application/json" \  -d '{    "store_id": "5f1c9b3a-1e2d-4c5b-8a9f-3d2e1c0b9a88",    "name": "My storefront"  }'

List an existing store's apps with GET /v1/user/stores/:storeId/oauth/apps, update with PUT, and remove with DELETE — all under /v1/user/stores/oauth/apps.

Exchange the client id/secret for an access token via POST /v1/auth/oauth/token — check GET /v1/oauth/scopes for the scope list an app can request.

Use a public token (generate one here) for read-mostly, customer-facing GraphQL calls made directly from the browser — it's scoped to one store and safe to expose. Use an OAuth app for server-side integrations that need write access (orders, cart mutations, admin operations).