Skip to main content
Vellaro has three levels of credentials, with clear boundaries.

​
1. Publishable key — identifies the store

  • What it does: tells the API which store. Like Stripe’s publishable keys, it can live in the client (web/mobile).
  • What it does NOT do: it does not authenticate a user and is rejected on /admin/* and /super-admin/*. The blast radius of a leaked key is limited to the storefront.
  • Format: cx_pk_<live|test>_<slug>_<random>. Use test only in development.
  • It can have origin restrictions and can be rotated/revoked by the operator.
If your calls originate from the store’s domain, the key is optional: the store is resolved from the domain. It’s needed for mobile apps and server-side clients without a domain.

​
2. Customer session — shopper account

For account areas (orders, addresses, wishlist, subscriptions) the customer logs in and gets a token:
Registration/login: POST /auth/register, POST /auth/login (with 2FA if enabled), POST /auth/refresh, Google OAuth. See the API Reference.

​
3. Staff token — Admin API

The /admin/* endpoints require a staff account (JWT) with the right permissions (catalog, sales, customers, content, marketing, reports, tax, users, system…).
  • The token carries the tenant_id claim: every session is bound to its store (leak-proof multi-tenant isolation).
  • Admin mutations are audit-logged.
  • Publishable keys never grant access here.
Never embed a staff token in a public client (web/mobile). The Admin API is for backends, server-side integrations, and automations (including the admin MCP).

​
Common auth error codes