Skip to main content
The workspace REST API allows 60 requests per minute per API key.
Other DMLY API surfaces have their own budgets. The reseller API allows 120 per minute per agency key, and the MCP server 120 per minute per key or OAuth connection. Each falls back to 60 per minute per IP address for a request with no credential it can resolve.
Each key gets its own budget. Two integrations calling from the same server (or the same office network) don’t compete, as long as they use separate keys. One more reason to create a key per integration rather than sharing one everywhere. Requests without a valid key (missing, mistyped, or revoked) share one 60/minute budget per IP address instead. They fail with 401 regardless; the shared bucket just caps how fast.

​
Headers

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

​
When you exceed it

You get 429 Too Many Requests, as JSON like every other error:
Wait the number of seconds in Retry-After (the message states the same figure), 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

Ten parallel workers on one key fight over the same 60/minute. One worker, spacing requests, finishes sooner, or give each worker its own key.
The budget belongs to the key, so a 429 you can’t explain means something else is calling with the same key: a second copy of your worker, a forgotten cron job, a colleague who pasted it into another tool. Give each integration its own key and the mystery disappears along with the shared budget.