Overview
The Configly API enforces per-key rate limits using a sliding window. Every API key has an hourly request budget based on your subscription tier. The API also applies IP-level brute-force protection to guard against credential-guessing attacks.
Tier limits
Rate limits are applied per API key over a rolling one-hour window.
| Tier | Soft limit (per hour) | Hard limit (per hour) |
|---|---|---|
| Trial | 50 | 150 |
| Solo | 100 | 300 |
| Multi-Instance | 500 | 1,500 |
| Agency | 2,000 | 6,000 |
The hard limit is always 3x the soft limit. If no subscription is detected, the trial tier applies by default.
Response headers
Every API response includes rate limit headers so you can monitor your usage:
| Header | Description |
|---|---|
X-RateLimit-Limit |
Your soft limit for the current window. |
X-RateLimit-Remaining |
Requests remaining before the soft limit. |
X-RateLimit-Reset |
Unix timestamp when the oldest request in the window expires. |
Retry-After |
Seconds to wait before retrying (only present on 429 responses). |
Soft limit
When you exceed the soft limit, the API returns 429 with error code RATE_LIMITED. The response includes a Retry-After header indicating how many seconds to wait.
{
"error": {
"code": "RATE_LIMITED",
"message": "Rate limit exceeded for this API key",
"status": 429,
"retryAfter": 45
}
}
Hard limit
When you exceed the hard limit (3x your soft limit), the API returns 403 with error code RATE_LIMITED. Your API key is immediately suspended, and an email notification is sent to the key owner. To resume, reactivate the key in the Configly connection settings.
{
"error": {
"code": "RATE_LIMITED",
"message": "API key suspended: hard rate limit exceeded",
"status": 403,
"softLimit": 100,
"hardLimit": 300
}
}
Brute-force IP protection
Repeated failed authentication attempts from the same IP address trigger temporary blocks with escalating durations:
| Failures | Window | Block duration |
|---|---|---|
| 5 | 10 minutes | 1 minute |
| 10 | 30 minutes | 5 minutes |
| 20 | 1 hour | 1 hour |
Blocked requests receive 429 with error code IP_BLOCKED and a Retry-After header.
Rate limit counters reset during scheduled maintenance restarts. This has no practical effect on well-behaved integrations.
Best practices
- Implement exponential backoff when you receive a 429 response.
- Respect the
Retry-Afterheader rather than using a fixed delay. - Monitor
X-RateLimit-Remainingto throttle proactively before hitting the limit. - Use a single API key per integration. Splitting requests across keys does not increase your budget.
- For key suspension and reactivation, see How to generate and manage API keys in the Getting Started section.
- For all error codes including
RATE_LIMITEDandIP_BLOCKED, see Error codes reference.
Comments
0 comments
Please sign in to leave a comment.