FraudEG API Rate Limits, Quotas, and Backoff Strategies

Rate limits protect the stability of the FraudEG platform and ensure fair, consistent performance for every customer. All accounts are subject to the default limits described on this page. If your integration requires higher throughput, contact the FraudEG sales team to discuss high-volume plans with elevated quotas.

Default Rate Limits

Rate limits are enforced per API key on a rolling one-minute window. Exceeding any per-endpoint limit or the global limit triggers a 429 Too Many Requests response.

Endpoint Group	Limit
`POST /v1/transactions/score`	1,000 req/min
`POST /v1/identity/verify`	200 req/min
`GET` endpoints (`/v1/events`, `/v1/alerts`)	500 req/min
All other `POST` endpoints	300 req/min
Global (all endpoints combined)	2,000 req/min

Sandbox API keys have lower rate limits — 100 req/min across all endpoints — to encourage efficient integration patterns and help you detect and fix unnecessary duplicate requests before going to production.

Rate Limit Response Headers

FraudEG includes rate limit headers on every response, not just error responses. Monitor these headers proactively to avoid hitting the limit rather than reacting after you receive a 429.

Header	Description
`X-RateLimit-Limit`	Your current rate limit for the endpoint that was called, in requests per minute.
`X-RateLimit-Remaining`	The number of requests remaining in the current window for this endpoint.
`X-RateLimit-Reset`	A Unix timestamp (seconds) indicating when the current window resets and `X-RateLimit-Remaining` returns to its maximum.
`Retry-After`	The number of seconds to wait before sending another request. Only present on `429` responses.

An example of the headers on a successful response:

HTTP/1.1 200 OK
X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 847
X-RateLimit-Reset: 1713984060
Content-Type: application/json

And on a 429 response:

HTTP/1.1 429 Too Many Requests
X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1713984060
Retry-After: 23
Content-Type: application/json

Handling 429 Errors

When you receive a 429 Too Many Requests response, read the Retry-After header and wait that many seconds before sending another request to the same endpoint. Do not retry immediately — doing so will not succeed and will extend the window in which your key is throttled.

Plan for gradual ramp-up when onboarding new traffic to FraudEG. Sudden bursts — such as replaying a backlog of transactions all at once — will immediately exceed rate limits and trigger 429 errors at scale. Spread high-volume jobs over time using a queue with a controlled dispatch rate.

Exponential Backoff Example

The following Node.js example wraps any API call with automatic retry logic that respects the Retry-After header and applies exponential backoff:

async function withRetry(fn, maxRetries = 3) {
  for (let attempt = 0; attempt <= maxRetries; attempt++) {
    const response = await fn();
    if (response.status !== 429) return response;
    const retryAfter = parseInt(response.headers.get('Retry-After') || '1');
    await new Promise(r => setTimeout(r, retryAfter * 1000 * Math.pow(2, attempt)));
  }
  throw new Error('Max retries exceeded');
}

Pass any function that returns a fetch Response object:

const result = await withRetry(() =>
  fetch('https://api.fraudeg.com/v1/transactions/score', {
    method: 'POST',
    headers: {
      'Authorization': 'Bearer <API_KEY>',
      'Content-Type': 'application/json',
      'Idempotency-Key': crypto.randomUUID(),
    },
    body: JSON.stringify({ transaction_id: 'txn_123', amount: 4999, currency: 'USD' }),
  })
);

Pair retry logic with the Idempotency-Key header so that retried POST requests never create duplicate resources, even when the original request may have partially succeeded before the rate limit was hit.

Best Practices

Follow these practices to stay well within your rate limits and build a resilient integration:

Cache risk scores for repeated lookups

If your system evaluates the same transaction multiple times — for example, during session replay or rule testing — cache the score response using the session_id combined with amount and user_id as a cache key. Avoid re-scoring identical inputs.

Use batch patterns for high-volume processing

For bulk operations such as historical data analysis or nightly report generation, spread requests evenly across the window using a job queue. Dispatch at a rate safely below your per-endpoint limit rather than sending all requests concurrently.

Monitor X-RateLimit-Remaining proactively

Read the X-RateLimit-Remaining header on every response. When the value drops below a threshold you define (for example, 10% of your limit), slow down your request rate before hitting zero. This prevents your integration from fully blocking on 429 responses during peak traffic.

Contact sales for higher limits

If your production workload consistently approaches the default limits, reach out to sales@fraudeg.com. High-volume plans offer elevated per-endpoint and global limits, as well as dedicated infrastructure for latency-sensitive use cases.

Overview

Transactions

Identity

Monitoring

FraudEG API Rate Limits, Quotas, and Backoff Strategies

Default Rate Limits

Rate Limit Response Headers

Handling 429 Errors

Exponential Backoff Example

Best Practices

​Default Rate Limits

​Rate Limit Response Headers

​Handling 429 Errors

​Exponential Backoff Example

​Best Practices

Default Rate Limits

Rate Limit Response Headers

Handling 429 Errors

Exponential Backoff Example

Best Practices