Rate limits

Request limits and payload caps. All of them are per integration, so they are yours alone to manage.

Request limits

Field	Type	Description
`All API calls`	per minute	300 per integration, and 600 per source IP. Whichever binds first.
`Booking writes`	per minute	60 — create, update and cancel share this budget.
`POST /sync`	per day	One per 24 hours. Six calls a day are accepted at the edge, refusals included, so a retry loop still gets cut off.

Exceeding any of them is 429 RATE_LIMITED, except the sync interval, which has its own 429 SYNC_TOO_SOON.

Reading a 429

Response 429 json

{
    "success": false,
    "code": "RATE_LIMITED",
    "message": "Too many requests. Retry after 34 seconds.",
    "errors": {
        "retry_after": 34
    }
}

The standard headers are set as well, and are the more convenient thing to read:

http

Retry-After:           34
X-RateLimit-Limit:     300
X-RateLimit-Remaining: 0

Wait Retry-After seconds and retry the same request. Do not retry immediately, and do not spread the same burst across more connections — the per-integration tier is keyed on your integration, not your socket.

Payload caps

Field	Type	Description
`Units per booking`	integer	20 entries in `units[]`.
`Adults or children per unit`	integer	50 each.
`Snapshot window`	integer	92 days per call.
`Snapshot horizon`	integer	730 days ahead of today.
`GET /events` page size	integer	200 per call.
`GET /bookings` page size	integer	200 per call.
`property_ids` on a sync	integer	500 ids.
`external_booking_id`	string	128 characters.
`notes`	string	2000 characters.
`reason`, `refund_note`	string	500 characters each.

Stay length is capped by the platform rather than by this API; a stay beyond the maximum is refused on check_out with the limit named in the message.

Webhook side

These are the limits Doorloom holds itself to when calling you.

Field	Type	Description
`Response deadline`	integer	10 seconds per delivery, configurable per integration between 1 and 30.
`Connect timeout`	integer	5 seconds.
`Delivery attempts`	integer	12, on the ladder 1m, 5m, 15m, 30m, 1h, then every 2h.
`Signature tolerance`	integer	300 seconds either side of `t`.
`Secret rotation overlap`	integer	24 hours during which both secrets verify.
`Event retention`	integer	30 days, which is also the replay window.
`Event horizon`	integer	365 days ahead by default, per integration.
`Window per event`	integer	Never more than one calendar month.

Designing within the limits

Do not poll what is pushed. If you subscribe to the calendar events you have no reason to call the snapshot endpoints on a schedule, and 300 requests a minute is generous for everything else.
Batch your reads. GET /bookings with updated_since and per_page=200 beats fetching bookings one at a time.
Treat a sync as an incident tool, not a routine job.
Back off on 429 rather than retrying tightly. The limiter is a fixed window; hammering it simply keeps you at zero remaining.

If the limits do not fit your volume

They are per integration and can be raised. Write to [email protected] with the shape of your traffic rather than engineering around them.