Overview

Rate limits protect the performance and availability of Dynamic Planner APIs by preventing excessive request volumes from individual consumers. Although rate limiting is not currently automatically enforced across the platform, monitoring is active and alerts may be triggered if a client significantly exceeds safe operational thresholds.

As automatic rate limiting will be introduced in the future, integrations should already be designed to gracefully handle potential 429 Too Many Requests responses using retry strategies and exponential backoff. Planning ahead ensures your integration remains resilient as the platform evolves.

Current Rate Limit Behaviour

Dynamic Planner currently uses monitoring-based rate control:

• No automated throttling or request rejection is applied today; all control is monitoring‑based.
• Usage is continuously monitored through platform logs.
• Automated notifications alert internal teams when high volumes occur.
• Customers may be contacted if traffic patterns show risk of system degradation.

As stricter enforcement will be introduced, you should implement defensive rate-limit handling now to ensure future compatibility.

Future Rate Limit Enforcement

Dynamic Planner will introduce automated rate limiting across API domains. Specific limits will be communicated in advance and may include:

• Per‑minute or per‑second request thresholds
• Burst tolerance windows
• Domain‑specific rate control (e.g., CRM vs Finances)
• 429 responses with retry timing guidance

When enforcement arrives, integrations that already handle retries and backoff will continue functioning without change.

Handling 429 Responses

Although 429 responses are not commonly returned today, integrations should already be prepared to handle them as part of future enforcement.

We recommend:

• Implement exponential backoff (e.g., 1s, 2s, 4s, 8s).
• Respect the Retry-After header when present.
• Ensure retries are idempotent to avoid duplicate operations.
• Monitor and log correlation IDs for later support.

Monitoring & Diagnostics

All requests to Dynamic Planner APIs include diagnostic metadata captured in logs:

• x-dt-traceid — client-supplied correlation ID
• x-dt-requestid — server-generated identifier for each request

These IDs are essential when investigating performance issues, unexpected throttling, or elevated request volumes. Internal systems raise automated alerts when usage spikes or exceeds expected thresholds.