Rate Limits
🚦 API Rate Limits
To ensure fair usage and protect the stability of the Scriptix platform, rate limiting is applied across all API endpoints. Exceeding the limits may result in temporary request blocking.
🔢 Standard Rate Limits
Request Type | Limit | Description |
---|---|---|
Batch API | 60 requests / minute | Applies to media uploads and session/document creation |
Realtime API | 1 connection / session | One WebSocket connection per session ID |
Custom Models | 30 requests / minute | Includes training, upload, and data model queries |
Webhook Callback | 5 retries / 10 minutes | If a webhook fails, it will be retried based on retry logic |
Reseller API | 100 requests / minute | For managing users, customers, and usage data |
⏳ Rate limits are applied per API token unless otherwise specified.
📛 Error Response on Throttling
When a client exceeds the rate limit, a 429 Too Many Requests
response is returned.
Sample Response
{
"error": "rate_limit_exceeded",
"message": "You have exceeded the allowed number of requests. Please wait and try again later."
}
🛠 Best Practices to Avoid Throttling
- Implement exponential backoff when retrying failed requests.
- Batch your operations whenever possible to reduce request volume.
- Avoid polling—use Webhook Callbacks for asynchronous updates.
- Cache static data (e.g., model lists or language info) instead of refetching on every request.
🔐 Webhook Rate Limits
To prevent abuse and ensure reliability, webhook delivery includes built-in rate limits:
- Must respond within 20 seconds
- Maximum of 5 retries with increasing delays (1 min, 3 min, 5 min, etc.)
- No further attempts after the 5th retry
Refer to Webhook Callback for detailed retry logic and security guidelines.
🧠 Use Cases
- Safeguard backend services against abusive clients
- Enforce fair access to shared infrastructure
- Prevent webhook loops or retry storms
- Enable scalable usage across large customer bases