Skip to main content

Rate Limits

To ensure fair usage and maintain service reliability for all partners, the Partner API implements rate limiting. These limits help protect our infrastructure and ensure consistent performance for all integrations.

Current rate limits​

The API enforces the following limits per app-site combination:

  • 180 requests per minute
  • 500 requests per 5-minute window

Rate limits are applied based on your unique combination of clientId and siteId parameters, ensuring that each site integration has its own allowance.

How rate limiting works​

  • Limits are enforced in rolling time windows (not fixed intervals)
  • Each client-site combination has separate rate limit counters
  • Cached responses do not count towards your rate limit - if we can serve your request from our cache, it won't consume any of your allowance
  • Rate limit counters reset automatically after the time window expires
info

We implement server-side caching for some responses, which means repeated requests for unchanged data may not count towards your rate limits. However, we recommend implementing your own caching strategy to minimise API calls and improve your application's performance.

Rate limit headers​

When you make API requests, you'll receive headers that help you monitor your usage:

  • X-RateLimit-Limit: Your total limit for the 1-minute window
  • X-RateLimit-Remaining: Remaining requests in the current 1-minute window
  • X-RateLimit-Limit-5m: Your total limit for the 5-minute window
  • X-RateLimit-Remaining-5m: Remaining requests in the current 5-minute window
  • Retry-After: Seconds to wait before retrying (when rate limited)

What happens when you exceed limits​

If you exceed the rate limit, you'll receive:

  • HTTP 429 Status Code (Too Many Requests)
  • Retry-After header indicating when you can make requests again
  • Your request will not be processed

Best practices for staying within limits​

  • Monitor the rate limit headers in API responses to track your usage
  • Implement exponential backoff when you receive 429 responses
  • Implement server-side caching in your application to avoid repeated requests for the same data
  • Batch operations where possible to reduce total request count
  • Spread requests evenly throughout the time window rather than bursting

Need higher limits?​

The current limits accommodate most typical integration patterns. If your use case requires higher limits, please contact your technical contact or support@utopi.co.uk with:

  • Details about your integration requirements
  • Expected request patterns and volumes
  • Business justification for increased limits

We'll review requests on a case-by-case basis and may adjust limits where appropriate.