Rate Limits

Overview

The DMTR API applies rate limits to protect service stability and ensure fair usage. Limits vary by tier and endpoint. Rate limit headers are included in every response; when limits are exceeded, requests return 429 with retry guidance.

Rate limit tiers

Rate limits are tiered by plan and endpoint type. Read-heavy endpoints (e.g., list positions, get by ID) typically have higher limits than write endpoints (e.g., create, update). Ingest and batch operations may have separate limits. Check your plan documentation for specific numbers.

Headers

Every response includes X-RateLimit-Limit (total requests allowed in the window), X-RateLimit-Remaining (requests left), and X-RateLimit-Reset (Unix timestamp when the window resets). Use these to throttle client-side requests and avoid hitting limits.

Handling 429 responses

When you receive 429, the response includes Retry-After (seconds to wait) when applicable. Implement exponential backoff: wait the suggested time, then retry. Avoid tight retry loops; respect the backoff to prevent sustained rate limiting.

{
  "code": "rate_limit_exceeded",
  "message": "Too many requests. Please retry after the specified time.",
  "retry_after": 30
}

Best practices

Implement client-side throttling based on X-RateLimit-Remaining. Use pagination to limit response size and request count. Batch operations where supported instead of many small requests. Cache read responses when appropriate. Monitor rate limit headers in production to tune your integration.