Rate limits
300 requests a minute per key, bursts allowed — the headers that tell you where you stand.
The API counts what each key asks for, so one system in a loop cannot slow down everyone else. The limits are generous for a CRM that acts when a person clicks; they are there for the loop.
Requests per key
Each key may make 300 requests a minute, bursts allowed: an unused minute's requests can be spent at once.
Every authenticated answer carries three headers, a 429
errors.api.rateLimitExceeded included:
| Header | What it says |
|---|---|
RateLimit-Limit | How many requests the key may make: 300. |
RateLimit-Remaining | How many are left right now. |
RateLimit-Reset | Seconds until the key is back at its full 300. |
A 401 carries none of them. Past the limit the answer is a 429
errors.api.rateLimitExceeded with a Retry-After header: wait that many seconds.
Failed authentication
Failed attempts are limited per address: 20 a minute by default. Only a
well-formed key that fails verification counts — unknown, wrong, revoked or expired. A
missing or malformed key counts for nothing, and this limit never refuses a key that
verifies. Once the attempts are spent, the answer is a 429
errors.api.tooManyFailedAuthentications with Retry-After — and only that header: the
key was never verified, so there is no RateLimit-*.
Budgets for creating
Some creating calls also have a budget per organisation, shared by every key of the organisation and separate from the request limit:
| What | Budget | Code on the 429 |
|---|---|---|
| Planning links | 120 a minute | errors.api.rateLimitExceeded |
| Invitations | 60 a minute and 5,000 a day | errors.api.rateLimitExceeded |
| Invitations to one customer (by e-mail address) | 10 a day | errors.api.customerInvitationLimit |
| Team members: create calls, repeats included | 200 an hour | errors.api.colleagueInvitationLimit |
| Resending one team member's invitation | 3 an hour | errors.api.colleagueInvitationLimit |
Every one of them answers with Retry-After. A 429 is never stored, so retry with the
same Idempotency-Key once the time has passed.
503 on a very large burst
A very large burst can be answered with a 503 before it reaches the API. Retry it with exponential backoff and some random jitter, so your retries do not arrive together.
Use webhooks instead of polling
To know when something changed, subscribe to webhooks rather than reading the same list again and again.
Frequently asked questions
Is the limit per key or per organisation?
The 300 requests a minute are per key. The budgets for creating are per organisation: a second key does not double them.
Can the limits be raised?
Write to support@schedulinq.com with what you are building and how many requests it needs.