Skip to main content
Ask ChatGPT

Rate Limiting

To ensure consistent performance, the REST API enforces a burst-based rate limit. Each environment is assigned a specific rate — for example, 15 requests per second, with an additional burst buffer of up to 100 requests. This setup allows short spikes in traffic to be processed immediately, improving responsiveness without compromising stability.

Resource-heavy actions (e.g., large downloads, complex transformations like watermarking or resizing, or large file uploads) may have a greater impact on performance. For higher throughput needs, contact your Account Executive to request a rate limit increase or optimization support.

⚙️ How It Works: Burst-Based Rate Limiting​

Your environment has two key limits:

  • Sustained Rate Limit: The number of requests allowed per second (e.g., 15 rps).
  • Burst Buffer: A short-term capacity (up to 100 requests) that allows for immediate processing during sudden spikes.

Once both the sustained rate and the burst buffer are exceeded, additional requests are rejected with an HTTP 429 Too Many Requests response.

🛣️ Analogy: The Toll Booth​

Think of your environment like a highway toll booth:

  • It allows 15 cars (requests) per second to pass through.
  • There is a burst lane for up to 100 additional cars that show up at once.
  • Once all lanes are full (15 rps + 100 burst), extra cars are turned away — shown a sign that says, “Too Many Cars – Try Again Later” (HTTP 429).

This new model eliminates silent delays and gives you immediate feedback when you hit the rate ceiling.

🔐 Enforcement and Responses​

Exceeding your environment's rate limit triggers:

  • HTTP 429 Too Many Requests responses.
  • No queuing of excess requests — they are rejected instantly.
  • The rate limit applies across all integrations in your environment.

Best practices to avoid hitting the limit:

  • Log 429 responses: Monitor which endpoints and patterns trigger them.
  • Retry with backoff: Wait before resending failed requests.
  • Distribute traffic: Spread out calls over time rather than batching them all at once.

📊 Example Scenario: 130 Requests at Once​

If your environment has a 15 rps limit and a 100-request burst buffer:

  1. 15 requests are processed immediately.
  2. 100 requests are also processed immediately via the burst buffer.
  3. Remaining 15 requests are rejected with a 429 Too Many Requests error.

🧠 Managing API Calls Effectively​

To optimize usage and avoid rate limit issues:

  • Space out job status checks: Use progressive waits (e.g., 1s, 3s, 5s).
  • Use select headers: Request related data in a single call using headers like {select-record: classifications}.
    • Select headers are unique to Aprimo DAM. Learn more in our Select Headers article.
  • Cache frequently accessed data to reduce redundant calls.
  • Use optimal upload settings: Upload in 20MB chunks.
  • Reuse access tokens until they expire to avoid excessive auth requests.

🗃️ Asset and Metadata Caching​

  • Filter for changes: Use the filter header to get only new or modified data.
  • Use webhook rules: Trigger app updates when relevant asset changes occur.
  • Cache static data (e.g., classifications) and refresh periodically.

🔍 Related Topic: System Performance​

Fewer API calls = better performance. Track performance with these methods:

  • Timing: Measure operation duration to find bottlenecks.
  • Proximity: Host your application near the DAM (e.g., same Microsoft Azure region) for better response times.

Need help optimizing your integration? Contact your Account Executive to discuss custom rate limits or architecture support.