Security
Authentication
Dishora authenticates with Bearer tokens. Treat your API key like a password: keys are scoped to an environment (sandbox or production) and can be rotated or revoked from the dashboard at any time.
How to authenticate
Send your API key in the Authorization header as a Bearer token on every request.
Authorization header
# Authenticated request: pass your API key as a Bearer token
curl https://api.dishora.app/api/v1/recipes/generate \
-H "Authorization: Bearer dsk_live_xxxxxxxxxxxxxxxxxxxx" \
-H "Content-Type: application/json"Key types
| Prefix | Environment | Notes |
|---|---|---|
dsk_test_ | Sandbox | Rate 10/min, never billed, cached responses. |
dsk_live_ | Production | Subject to your tier’s limits and quotas. |
Keep keys secret
Never embed production keys in client-side code or public repos. Proxy requests through your own backend, and use the sandbox key for any client-side experimentation.
User vs. developer tokens
Two token models exist in the Dishora platform:
- Developer API keys (
dsk_): for third-party apps calling the public API. Rate-limited per key. - User session tokens (Sanctum): issued to the Dishora mobile app after login/OAuth. Scoped to a single user’s data.
The sellable endpoints (/v1/recipes) accept either token type, so the same integration works for the mobile app and for third-party developers. If you’re building on behalf of an end user (e.g., an import tool), use OAuth to obtain a user-scoped token. For server-to-server recipe generation, use a developer API key.
Errors
A missing or invalid key returns 401 Unauthenticated:
401
{
"message": "Unauthenticated."
}