Error Response Format
All API errors follow a consistent format:| Field | Description |
|---|---|
message | Human-readable description of what went wrong |
type | Category of error (e.g., authentication_error, validation_error) |
code | Specific error code for programmatic handling |
param | The request parameter that caused the error (if applicable) |
HTTP Status Codes
| Status | Description |
|---|---|
200 | Success |
201 | Created (for POST requests that create resources) |
400 | Bad Request - Invalid parameters or malformed request |
401 | Unauthorized - Invalid or missing API key |
402 | Payment Required - Insufficient credits |
403 | Forbidden - Access denied to resource |
404 | Not Found - Resource doesn’t exist |
429 | Too Many Requests - Rate limit exceeded |
500 | Internal Server Error - Something went wrong on our side |
503 | Service Unavailable - Temporary outage |
Error Types
Authentication Errors (401)
| Code | Description | Solution |
|---|---|---|
missing_api_key | No Authorization header | Add Authorization: Bearer <key> header |
invalid_api_key | Key format invalid or doesn’t exist | Check key format starts with mvra_live_ |
revoked_api_key | Key has been revoked | Create a new API key |
Validation Errors (400)
| Code | Description | Solution |
|---|---|---|
invalid_model | Invalid model specified | Use mavera-1 |
missing_field | Required field not provided | Include the required field |
invalid_field | Field value is invalid | Check field requirements in API reference |
invalid_persona | Persona ID doesn’t exist | List personas to get valid IDs |
Credit Errors (402)
| Code | Description | Solution |
|---|---|---|
credits_exhausted | No credits remaining | Upgrade plan or wait for reset |
budget_exceeded | Workspace/project budget limit hit | Increase budget or wait |
Rate Limit Errors (429)
Retry-After header for how long to wait.
Not Found Errors (404)
Server Errors (500, 503)
Handling Errors in Code
Retry Strategy
For transient errors (429, 500, 503), implement exponential backoff:Debugging Tips
Log request and response details
Log request and response details
Include request ID, timestamp, and full error response in logs for debugging.
Check the param field
Check the param field
The
param field tells you exactly which field caused validation errors.Verify API key format
Verify API key format
Keys must start with
mvra_live_ and be exactly as copied from the dashboard.Test with curl first
Test with curl first
Isolate issues by testing the raw API with curl before debugging SDK code.
Request IDs
Some error responses include arequest_id (or similar) in the response headers or body. If present, include it when contacting support—it helps us locate the exact request in our logs.
Logging for Support
When reporting issues, provide structured information. Never log or share your full API key—only the prefix (e.g.mvra_live_abcd...).
| Field | Include |
|---|---|
Error code | From error.code |
Error message | From error.message |
param | From error.param (for validation errors) |
| HTTP status | e.g. 401, 402, 429 |
| Endpoint | e.g. /responses |
| Timestamp | When the error occurred |
| Request ID | If returned in headers |
| API key prefix | First 10 characters only |
Getting Help
If you encounter persistent errors:- Check our status page for outages
- Review the error message and code
- Contact support@mavera.io with:
- Error message and code
- Request details (endpoint, parameters)
- Timestamp
- Request ID (if available)
- Your API key prefix (first 10 characters only)
Error Handling Patterns
Retries, backoff, user-facing messages
Authentication
Fix 401 errors
Rate Limits
Handle 429
Credits
Handle 402