Support & Troubleshooting
Rate Limits & Error Handling
The Fastino Personalization API enforces rate limits and returns standardized error objects for all endpoints. This ensures consistent, predictable behavior and clear recovery paths for all client applications.
Overview
All API responses follow a consistent error schema and include headers that describe your current rate-limit state.
You should implement:
Graceful retry logic for
429 Too Many Requestsresponses.Exponential backoff for burst requests.
Consistent error handling based on structured JSON error objects.
Rate Limits
Rate limits vary depending on environment and authentication scope.
Environment | Default Limit | Notes |
|---|---|---|
Production | 60 requests / minute | Temporary data, relaxed limit. |
Enterprise / Partner | Configurable up to 2,000 requests / minute | Contact support for adjustment. |
Rate-Limit Headers
Every response includes headers describing your remaining quota and reset window.
Header | Description | Example |
|---|---|---|
| Maximum allowed requests per minute. |
|
| Remaining requests in the current window. |
|
| UTC timestamp when the limit resets. |
|
Example
Handling Rate Limit Exceedance
If you exceed the allowed number of requests per minute, you’ll receive a 429 Too Many Requests response:
Response
Body
Your client should respect the Retry-After header and pause requests for that number of seconds before retrying.
Error Response Schema
All Fastino API errors share a consistent JSON structure:
The code field is machine-readable and suitable for programmatic handling.
The message field provides a human-readable explanation.
The optional details object gives diagnostic context for logs or dashboards.
Common Error Codes
Error Code | HTTP Status | Meaning | Recommended Action |
|---|---|---|---|
| 404 | No user found for the given | Verify user exists or register them first. |
| 400 | Request body or parameters malformed. | Check required fields and JSON structure. |
| 429 | Too many requests within time window. | Wait for |
| 401 | Invalid or missing API key. | Check your Bearer token. |
| 403 | Key valid, but lacks required permissions. | Use a scoped key with appropriate access. |
| 500 | Internal processing failure. | Retry after a short delay; contact support if persistent. |
| 504 | Request exceeded processing time. | Retry with smaller payload or fewer results. |
Example: Invalid Request Error
Body
Example: User Not Found
Body
You can handle this by re-registering the user:
Example: Unauthorized
Body
Check that your requests include:
Example: Server Error
Body
If this error persists, log the request_id from the details field and contact support.
Retry Guidelines
Error Code | Retry Strategy | Delay |
|---|---|---|
| Wait for | Typically 15–60s |
| Retry with exponential backoff (max 3x). | 2s → 4s → 8s |
| Retry once with smaller payload. | 5s |
| Do not retry automatically. | Manual fix required. |
Example: Exponential Backoff (Python)
Monitoring and Logging
Always log the
request_idfromerror.detailsfor traceability.Aggregate rate-limit headers to monitor usage trends.
Surface
RATE_LIMIT_EXCEEDEDandSERVER_ERRORin application dashboards for early alerts.Consider caching frequent
/summaryor/queryresponses to reduce duplicate requests.
Summary
Fastino’s rate limiting and standardized error handling ensure that your integrations remain stable, predictable, and diagnosable at scale.
Implement exponential backoff, respect Retry-After intervals, and always parse the structured JSON error schema for resilient, production-grade client behavior.
Next, continue to Core Concepts → Authentication & Security to learn about key scopes, header configuration, and best practices for secure API usage.
Join our Discord Community