Rate limits
Each application has its own rate limit, set by the plan of the company that owns it:
| Plan | Requests per second | Burst |
|---|---|---|
| Free | 10 | 20 |
| Pro | 50 | 100 |
| Enterprise | 200 | 400 |
The limit is a token bucket: you can send up to the burst size at once, and the bucket refills at the per-second rate. Over the limit, requests fail with 429 rate_limited and a Retry-After header giving the seconds to wait. There are no X-RateLimit-* headers.
One availability request can cover up to 100 people and 200 periods. Batch participants into one call instead of calling once per person.
Google and Microsoft also limit how often a calendar can be read and written. When they push back, BentoCal returns 502 provider_unavailable (or a provider_unavailable participant error) with a Retry-After header.
Request limits
| Limit | Value |
|---|---|
| Request body | 1,000,000 bytes |
| Your user ids and event ids | 1 to 255 characters. User ids can't start with bentocal-test:. |
| Users per free/busy request | 100 |
| Participants per availability request | 100 |
calendar_ids per user | 50 |
Date range (free/busy start to end, or all availability periods) | 62 days |
| Periods per availability request | 200 |
| Slot duration and interval | 5 to 1440 minutes, in multiples of 5 |
| Buffers before and after | 0 to 240 minutes, in multiples of 5 |
Event summary | 1,024 characters |
Event description | 8,192 characters |
Event location | 1,024 characters |
Event time_zone | 64 characters |
Requests over these limits fail with 400 invalid_request, and details.issues says which field.
Account limits
| Limit | Value |
|---|---|
| Connections in development applications | 10 per company, across all regions |
| Test calendars (console Testing tab) | 5 per application |
| Redirect URIs | 20 per application, each up to 2,048 characters |
| Connect session lifetime | 30 minutes, then the session is expired |
See Development and production for how the development limit works.