API Rate Limits

We have rate limits in place for our APIs and Applications. These are in place to enforce fair usage and protect against malicious behavior.

The rate limits are enforced by IP address.

Currently, the rate limit is set to 6,000 requests over a 5-minute window (i.e. 20 requests per second)

Exceeding a rate limit

Any requests above the rate limit will receive a 429 HTTP status code (Too many requests) and can be retried once the limit is not exceeded.

What if I need more requests?

We believe that all applications should work within these limits.

Our webhooks system is available which can prevent your app from polling Administrate for changes but instead be notified when a change occurs.

Webhook Rate Limits

We enforce fair use guidelines for webhook executions across multiple time windows:

What Counts Toward Limits

• ✅ Active webhook executions
• ✅ Disabled webhook executions (payload is still calculated)
• ✅ Filtered webhook executions, including events that do not match the filter (the payload is still calculated in order to evaluate the filter)
• ✅ Failed webhook attempts (including retries)
• ✅ Successful webhook deliveries

What Happens When Guidelines Are Exceeded

Automatic Actions

• Webhooks may be throttled and retried at a later time

Retries and Throttling

When an execution is throttled it is not discarded. Instead it is retried with an exponential backoff (up to 3 times — after 30 seconds, 1 minute and 2 minutes; see request failures and reattempts).

Each attempt — the initial execution and every retry — produces its own log entry. A burst of triggered events can therefore generate several times as many log entries as events, since each event may be retried multiple times before it succeeds or is recorded as a failure.

Automatic Deactivation

An event that exhausts all of its retries is recorded as a failure for that webhook. If a single webhook accumulates 100 failures within a 24-hour window, it is automatically marked as inactive as a safety measure to protect both Administrate and your receiving endpoint, and the addresses on the webhook's notificationEmails are notified.

Escalation Scenarios

We will mark webhooks as inactive and notify you, especially when executions are: - Returning failing HTTP status codes (4xx, 5xx) - Triggering excessive retries due to timeouts - Impacting other customers' webhook performance

Monitoring Your Usage

Check Your Current Usage

• View webhook execution metrics in your Control Panel
• Monitor response times and error rates on receiving endpoints

Best Practices

• Implement proper error handling to reduce retries
• Use webhook filtering to receive only relevant events
• Optimize your endpoint response times (aim for <5 seconds)
• Return appropriate HTTP status codes (see retries)