#
The Xentropy API uses Supabase JWT tokens for authentication. All API requests must include a valid Bearer token in the Authorization header.
#
| Token | TTL | Usage | |-------|-----|-------| | Access Token | 1 hour | Standard API authentication | | Refresh Token | 30 days | Obtaining new access tokens | | Personal Access Token | Custom | Long-lived API access (coming soon) |
#
#
When logged into Xentropy, your access token is managed automatically. The app refreshes it transparently.
#
POST /api/auth/v1/token?grant_type=password
Content-Type: application/json
{
"email": "your@email.com",
"password": "your-password"
}
Response:
{
"access_token": "eyJhbGciOiJIUzI1NiIs...",
"expires_in": 3600,
"refresh_token": "6Vh2QXw7T3...",
"token_type": "bearer"
}
#
Include the token in all API requests:
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
#
curl -H "Authorization: Bearer YOUR_TOKEN" \
https://api.xentropy.ai/api/content
#
const response = await fetch("https://api.xentropy.ai/api/content", {
headers: {
Authorization: `Bearer ${token}`,
},
});
#
When the access token expires, use the refresh token to get a new one:
POST /api/auth/v1/token?grant_type=refresh_token
Content-Type: application/json
{
"refresh_token": "6Vh2QXw7T3..."
}
#
Xentropy supports asymmetric JWT verification (ES256/RS256 via JWKS) in addition to the legacy HS256 symmetric verification. This means:
- Tokens are verified using Supabase's published JWKS endpoint
- Algorithm confusion attacks are prevented
- No shared secret needed for verification
#
| Status | Code | Meaning |
|--------|------|---------|
| 401 | UNAUTHENTICATED | Missing or invalid token |
| 401 | TOKEN_EXPIRED | Token has expired — refresh it |
| 403 | FORBIDDEN | Token is valid but lacks permissions |
| 429 | RATE_LIMITED | Too many requests — slow down |
#
Long-lived tokens for programmatic access, suitable for:
- MCP server authentication
- CI/CD pipelines
- Third-party integrations
- Custom tooling
Personal Access Tokens will be manageable from your account settings.