Youtrust applies rate limits across all API endpoints to ensure reliability and fair usage.

Limits are enforced per minute and per hour. If you exceed either threshold, the API returns and HTTP 429 error with the message Too many requests. Limits differ between the Sandbox and Production environments.

Default limits

📊 Usage monitoring

To help you manage your consumption, every API response includes headers indicating your current usage and remaining quota.

Every API response includes headers that expose both your limits and your remaining quota for the current minute and hour:

• x-ratelimit-limit-minute
• x-ratelimit-remaining-minute
• x-ratelimit-limit-hour
• x-ratelimit-remaining-hour

Rate limits are reset at the beginning of each minute and hour. You can use the Ratelimit-Reset header to determine exactly how many seconds remain until the minute quota is refreshed.

Example response headers:

HTTP/2 429 
< x-ratelimit-limit-hour: 1200
< x-ratelimit-limit-minute: 60
< x-ratelimit-remaining-hour: 1197
< x-ratelimit-remaining-minute: 59
< Ratelimit-Reset: 45

In this example, you have 59 requests remaining for the current minute, and the counter will reset in 45 seconds. We recommend using these headers to programmatically adapt your integration and avoid hitting the limit.

Rate limiting headers are included in API responses when the rate limiting service is operational. In rare situations where the rate-limiting backend is temporarily unreachable, these headers may be absent from the response. This is intentional best-effort behavior: when rate-limiting metadata is unavailable, API requests are still processed, and all calls will succeed — the rate-limiting policy is simply not enforced during that period. This behavior is specific to rate limiting headers. All other response headers are always present as documented.

Implementation guidance: Your integration should not treat the absence of rate limiting headers as an error. Always check for header presence before reading their values. This guideline will also be added to our Public API Documentation

When you hit the limit

If a request is rejected because a threshold is exceeded, you receive a 429 HTTP response and the message Too many requests.

Here are our recommendations to deal with this situation:

• Stop or slow down the request throughput.
• Retry after a delay and increase the delay if you keep receiving 429 responses.
• Avoid parallel, immediate retries; queue and space out requests until your minute/hour budget recovers.

Best practices to stay within limits

• Prefer Webhooks over polling to track status changes and events. See our Webhooks guide.
• If you must poll, keep the frequency to a strict minimum and only fetch information when needed.
• Cache and reuse data that does not change frequently to reduce repeated GET calls.
• Queue API calls and avoid concurrency to smooth out traffic spikes.

📏The rate limit policy can be customised to fit your needs

For integrations requiring higher throughput, you may request an adjustment to your API rate limits.

The prerequisite is adherence to our integration best practices, especially using Webhooks instead of polling, controlling concurrency, and applying backoff on retries.

How to request a rate limit change?

1. Please ensure you have an active API Key in the target environment: Sandbox or Production.
2. Complete the form providing detailed information about your use case and implementation (expected average and peak request rates, concurrency and retry strategy already implemented, event handling approach)

Upon receipt, our support team will review your request and may contact you to confirm the changes or request additional information.