Skip to main content
The API allows 60 requests per minute.
The limit is counted per IP address, not per API key. Every key calling from the same outbound IP shares one 60/minute budget. If several integrations run from one server — or from the same office network — they compete for the same allowance.

Headers

Every response carries your current standing, so you rarely need to guess:

When you exceed it

You get 429 Too Many Requests:
Send Accept: application/json on every request. The rate limiter sits in front of the API’s JSON error handling, so a 429 to a client that didn’t ask for JSON comes back as an HTML error page — which will blow up a naive response.json() in your retry path. Every other status returns JSON either way; 429 is the exception.
Wait the number of seconds in Retry-After, then retry. Retrying sooner just burns another request and extends the problem.

Staying under the limit

1

Page in hundreds, not tens

?per_page=100 fetches the same data in a quarter of the requests that the default 25 would need. See Pagination.
2

Use webhooks instead of polling

Polling for new messages every few seconds will exhaust the budget on its own. Subscribe to events and let DMLY call you.
3

Watch the remaining header

Read X-RateLimit-Remaining and slow down as it approaches zero, rather than waiting to be refused.
4

Serialise bulk jobs

Importing thousands of contacts in parallel from one host will hit the limit. One worker, spacing requests, finishes sooner than ten workers fighting each other.
Because the limit is per IP, a 429 can be caused by something other than your own code — another integration behind the same NAT, for example. If a 429 looks inexplicable, check what else calls DMLY from that network.