Rate Limiting | WealthGuard API Documentation

Overview

WealthGuard implements rate limiting to ensure platform stability, fair resource distribution, and security across all API endpoints. Rate limits are enforced per API key and apply to both synchronous and asynchronous requests.

Note: Rate limits are evaluated on a rolling window basis. Exceeding limits will result in an HTTP 429 Too Many Requests response.

Our limiting strategy uses a token bucket algorithm combined with fixed-window counters for burst protection. This allows for smooth request flow while preventing sudden traffic spikes from degrading service quality.

Rate Limit Tiers

Rate limits vary based on your subscription plan and API key tier. Custom enterprise limits are available upon request.

d>

Limit Type	Starter	Professional	Enterprise
Requests / Minute	60	600	Custom
Requests / Hour	1,000	15,000	Unlimited*
Burst Limit (sec)	10	50	Configurable
Concurrent Requests	5	50	200+

Important: Enterprise "Unlimited" hourly limits still enforce per-minute and concurrency caps to protect infrastructure. Contact your CSM for specific configurations.

Response Headers

Every WealthGuard API response includes rate limit headers to help you monitor your usage in real-time.

                            HTTP Headers
                            
                        
X-RateLimit-Limit: 600
X-RateLimit-Remaining: 482
X-RateLimit-Reset: 1715483200
Retry-After: 45 # Only present on 429 responses

X-RateLimit-Limit: Maximum requests allowed in the current window
X-RateLimit-Remaining: Requests left before hitting the limit
X-RateLimit-Reset: Unix timestamp when the window resets

Handling 429 Errors

When you exceed your rate limit, WealthGuard returns a 429 Too Many Requests status code with a structured JSON body.

                            429 Response
                            
                        
{
  "error": {
    "code": "rate_limit_exceeded",
    "message": "You have exceeded your rate limit. Please wait before making another request.",
    "retry_after": 42,
    "limit": 600,
    "remaining": 0
  }
}

Critical: Never ignore 429 responses. Continuing to send requests while limited may result in temporary API key suspension or IP blocking for abuse prevention.

Best Practices

1. Implement Exponential Backoff

When receiving a 429, wait for the Retry-After duration, then retry with exponential backoff. Add jitter to prevent thundering herd scenarios.

JavaScript Example

async function requestWithRetry(url, options, retries = 3) {
  for (let i = 0; i <= retries; i++) {
    const res = await fetch(url, options);
    if (res.status === 429) {
      const retryAfter = res.headers.get('Retry-After') || 2 ** i + Math.random();
      console.log(`Rate limited. Retrying in ${retryAfter}s...`);
      await new Promise(r => setTimeout(r, retryAfter * 1000));
      continue;
    }
    return res;
  }
  throw new Error('Max retries exceeded');
}

2. Cache Aggressively

Cache static or infrequently changing data (account details, historical quotes, user profiles) to reduce redundant API calls.

3. Batch Requests When Possible

Use our bulk endpoints where available. A single batched request counts as one against your limit instead of multiple individual calls.

Frequently Asked Questions

Higher limits are available through plan upgrades or custom enterprise agreements. Contact our sales team or submit a support ticket with your use case and expected traffic patterns.

Yes, all endpoints under your API key share a unified rate limit pool. This prevents complex tracking and ensures predictable behavior across your integration.

Automated IP blocks trigger after repeated 429 violations within a short window. You'll receive an email notification with steps to appeal. Permanent blocks only occur for malicious activity.

No. Webhooks are outbound notifications from WealthGuard to your server and do not count against your inbound API rate limits.