How it works
All Oshara REST endpoints used by third-party integrations authenticate with a JWT bearer token:
Authorization: Bearer <access-token>The widget’s session-start endpoint is the one exception — it’s gated by Origin whitelisting instead (see Origin whitelisting below) so it can be called from the browser without exposing a token.
Getting a token
Sign up
curl -X POST https://api.oshara.ai/api/auth/signup/ \
-H "Content-Type: application/json" \
-d '{"email": "you@example.com", "password": "••••••••"}'Log in
curl -X POST https://api.oshara.ai/api/auth/login/ \
-H "Content-Type: application/json" \
-d '{"email": "you@example.com", "password": "••••••••"}'Response:
{
"access": "eyJhbGci...",
"refresh": "eyJhbGci..."
}| Token | Lifetime |
|---|---|
access | 10 days |
refresh | 30 days |
Refresh
curl -X POST https://api.oshara.ai/api/auth/refresh/ \
-H "Content-Type: application/json" \
-d '{"refresh": "eyJhbGci..."}'Using the token
Include the access token in every authenticated request:
curl https://api.oshara.ai/api/ai-characters/ \
-H "Authorization: Bearer eyJhbGci..."Google OAuth
# Step 1 — redirect your user to this URL
GET /api/auth/google/
# Step 2 — Google redirects back to your callback
GET /api/auth/google/callback/?code=...The callback returns the same {access, refresh} JSON.
Current user
curl https://api.oshara.ai/api/auth/me/ \
-H "Authorization: Bearer <token>"Origin whitelisting
The widget’s session-start endpoint checks the Origin header of the browser request against the allowed_origins list on the AI character. Requests from non-whitelisted origins receive a 403 Forbidden.
Configure allowed origins in the dashboard under Characters → [character] → Allowed Origins, or via the Characters API.
{
"allowed_origins": [
"https://mysite.com",
"https://staging.mysite.com"
]
}Origins are matched as URL prefixes — https://mysite.com allows all pages under that domain.
Origin checking is skipped when DEBUG=True on a self-hosted backend to simplify local development.