Skip to content
MapleGatherMapleGather Help

API rate limit exceeded

Your integration is receiving 429 Too Many Requests responses from the MapleGather API.

What’s happening

Section titled “What’s happening”

The MapleGather API enforces rate limits to ensure reliable performance for all organizations. When your integration exceeds the allowed request rate, the API returns 429 and temporarily blocks further requests until the window resets.

Every API response includes rate-limit state in the headers:

Header Meaning
X-RateLimit-Limit Maximum requests allowed in the current window
X-RateLimit-Remaining Requests remaining in the current window
X-RateLimit-Reset Unix timestamp when the window resets

A 429 response includes a Retry-After header specifying how many seconds to wait before retrying.

The burst tolerance is up to 200 requests over any 10-second window. Sustained traffic above the per-window limit also triggers 429.

How to fix it

Section titled “How to fix it”
  1. Read X-RateLimit-Remaining before making requests. If it is 0, wait until X-RateLimit-Reset before sending more.
  2. On receiving a 429, read the Retry-After header value (seconds) and wait that long before retrying.
  3. Implement exponential backoff with jitter in your retry logic — do not immediately re-send on 429. A simple exponential-backoff formula: wait min(2^attempt * base_delay + random_jitter, max_delay) seconds between retries.
  4. When retrying a POST or PATCH that returned 429, use the same Idempotency-Key as the original request. This ensures the operation is executed only once even if both the original and the retry eventually succeed.
  5. For bulk operations, use the batch endpoint (POST /bc/v1/orgs/{orgId}/batch) to send up to 100 operations in a single request rather than making 100 individual API calls.

If that didn’t work

Section titled “If that didn’t work”

If your integration consistently hits rate limits even with backoff and batching, consider:

  • Spreading requests over time (for example, staging a bulk member import in smaller chunks with delays).
  • Using webhooks instead of polling — subscribe to member.created or payment.succeeded events and receive data pushed to your endpoint rather than repeatedly fetching it.

Contact support if you have a legitimate use case that requires a higher throughput allocation.

Section titled “Related”