Start Here – The 30-Second Fix: Check Your Client Code
This sounds dumb, but I've seen devs spend hours on server settings when the problem was right in their app. Last month, a client's Point-of-Sale system kept returning 'Throttling Limit Exceeded' every time they ran a report. Turned out their frontend was firing 20 requests per second instead of 2 because of a bad setInterval in JavaScript. Check your client-side retry logic first.
If you're using a popular SDK like boto3 (for AWS), or the Node.js client, look for loops that hammer the API. Add a simple exponential backoff – but first, just slow it down manually. Open your browser's dev tools or use a tool like Postman. Send one request. Does it work? Good. Send 5 requests in quick succession. If you get a 429, your client is the cause.
Real fix: add a 200ms delay between requests in your client code. For Python with requests:
import time
import requests
url = 'https://your-api-url.com/endpoint'
for i in range(5):
response = requests.get(url)
if response.status_code == 429:
print('Hit limit, waiting...')
time.sleep(0.5)
else:
print('Success:', response.status_code)
If that doesn't fix it, move on to the next step.
Moderate Fix (5 Minutes): Check Your API Gateway Throttling Settings
If your client code is clean, the issue is likely at the server. For AWS API Gateway, you've got two limits that matter: burst limit and rate limit. The default burst limit is 5000 requests per second, and rate limit is 10,000 requests per second (varies by region). But those are per-account limits – if you have multiple APIs under the same account, they share that bucket.
Log into the AWS Console. Go to API Gateway > your API > Stages > select your stage > Settings tab. Look for 'Throttling'. The key fields:
- Rate (requests per second) – steady-state limit
- Burst (requests per second) – spikes allowed for a short time
If you see values like 1000 and 500, that's likely too low for your traffic. Bump them up. But don't go crazy – if you set burst to 10,000 and rate to 5,000, you might hit your account's global limit and affect other APIs.
Real-world example: A client's e-commerce site went viral on Reddit. Their API Gateway had default limits. They started getting 429 errors for all users. I bumped the rate to 50,000 and burst to 25,000 (they had a high enough account limit). Problem solved in 3 minutes.
Warning: Increasing limits costs more money – each request is billed. But it's cheaper than losing customers.
Advanced Fix (15+ Minutes): Check Usage Plans and API Keys
If you're still hitting throttling after adjusting settings, it's probably a Usage Plan issue. This happens when you're using API keys and a usage plan that has its own throttling limits. The usage plan limits override the stage-level limits.
Go to API Gateway > Usage Plans > select your plan. Look at 'Throttling' and 'Quota' settings. The throttling limit here is per API key, not per account. So if you have 100 users sharing one API key, each request counts against the same limit. That's a common gotcha.
Fix option 1: Increase the usage plan throttling limits – set rate to 100,000 and burst to 50,000 if your account can handle it.
Fix option 2: Generate separate API keys for heavy users, so they don't exhaust the shared pool. You can do this in the API Keys section. Then attach each key to its own usage plan with higher limits.
Fix option 3 (the one I rarely recommend): Remove the usage plan entirely and rely on stage-level throttling. This works if you don't need per-client tracking. But you lose the ability to meter usage and generate reports.
Here's the command-line way to check your current usage plan limits using AWS CLI:
aws apigateway get-usage-plan --usage-plan-id YOUR_PLAN_IDReplace YOUR_PLAN_ID with your plan ID (found in the API Gateway console). It'll show you the throttling and quota settings.
Still Stuck? Check Your Backend's Actual Capacity
I had a case where the API Gateway wasn't the bottleneck – the backend Lambda function was. The function took 3 seconds to run, and when traffic spiked, it queued up requests. The client saw 429 errors because the API Gateway started throttling after too many queued requests hit the backend timeout.
Check your Lambda concurrency limits (default is 1000 per region). If you're getting close, request a limit increase from AWS Support. Or add an SQS queue between the API Gateway and Lambda to buffer requests – but that's a whole other article.
My takeaway: 90% of 429 errors are from bad client code or low usage plan limits. The other 10% need backend fixes. Start with the 30-second check, then move to settings. You'll save yourself hours.