Skip to main content

Command Palette

Search for a command to run...

intermediate10 minutes

Authentication

How Tenders-SA authenticated app and API routes currently authorize requests

Overview

Tenders-SA currently authenticates user-facing application routes with the same JWT issued by login and registration. The token is set as an httpOnly token cookie and is also returned in the auth response for existing client-side flows that still send Authorization: Bearer <token> headers.

No standalone API-key console

A separate self-service API-key console is not part of the current user-facing product. Do not build integrations around X-API-Key, external SDK package names, or /v1/auth/test examples unless a future developer API spec explicitly ships those features.

Login

POST /api/auth/login accepts an email and password, validates the account, applies login rate limiting, and returns the authenticated user, company context, JWT token, and optional CSRF token.

Login request

http

Login response shape

json

Registration

POST /api/auth/register creates the user, company profile, trial subscription, consent records, and email verification token. It sets the same httpOnly token cookie and returns the token in the JSON body for current app compatibility.

Registration request

http

Using Authenticated Routes

Browser clients can rely on the httpOnly cookie set by the auth routes. Existing client code may also send the JWT as Authorization: Bearer <token> while the localStorage token migration remains incomplete.

Authenticated fetch

javascript

Common Authentication Errors

| Status | Meaning |
|--------|---------|
| 400 | Invalid registration or request body validation failed |
| 401 | Missing, expired, or invalid JWT |
| 403 | The authenticated user does not have access to the requested company resource |
| 429 | Login or registration rate limit exceeded |

Related Guides

For account-level guidance, see Account Setup. For document vault endpoints, see Documents API. For tender data routes, see Tenders API.