Authentication and authorization model
Authentication answers "who is calling?" Authorization answers "may this caller perform this action on this resource?" TaruviBase checks both on every protected request.
Credentials
| Credential | Header | Where it comes from | Use it for |
|---|---|---|---|
| Session token | X-Session-Token: TOKEN | A user signing in through TaruviBase's hosted sign-in | Browser and mobile apps acting as a signed-in user |
| API key | Authorization: Api-Key TARUVI_API_KEY | Generate API Key on an app's Settings → Connect page, or API tokens | Servers, scripts, CI/CD, and AI tools |
| JSON Web Token | Authorization: Bearer TOKEN | TaruviBase's token endpoint | Server integrations that already use JWTs |
Keep API keys and tokens on the server. Never put an API key in browser code, a mobile app bundle, or a public build variable.
The JavaScript SDK signs users in with the hosted sign-in flow and sends their session token. The Python SDK accepts an API key, a session token, or a JWT — see Python SDK.
Authorization
Once TaruviBase knows who is calling, it checks the caller's roles and your app's access policies for the requested action. Policies can allow or deny an action, and can limit which records the caller sees.
Reading failures
| Status | Meaning | What to check |
|---|---|---|
401 | The credential is missing, invalid, or expired | Sign in again, or generate a new API key from the same site |
403 | The caller is known but not allowed to do this | The caller's roles and the app's access policies |
404 | The site, app, or resource was not found for this caller | TARUVI_SITE_URL, APP_SLUG, and the resource name or ID |
Error responses include a code and message that explain the failure.