Implementing API Rate Limiting with n8n, Airtable & Redis

Opening Problem Statement: Managing API Rate Limits for a Pokemon Data Service

Meet Sarah, a developer who manages a public API for a Pokemon database hosted on Airtable. Every hour, hundreds of users query this API to get detailed Pokemon information. However, Sarah recently noticed frequent server slowdowns and API abuse — some users bombarding the system with too many requests, causing degraded performance and higher costs. She struggles to control API consumption because the database and endpoints are not rate-limited, resulting in wasted server resources and unhappy users experiencing delays or errors.

Specifically, Sarah observed that without any usage limits, some API keys made tens of requests per minute and hundreds per hour, leading to data access delays and operational headaches. She needs a way to throttle this API usage by tracking requests per user (identified by API keys) and enforce limits like 10 requests per minute and 60 per hour to provide a fair and smooth experience.

What This Automation Does

This n8n workflow sets up an effective API rate limiting system using Redis and Airtable with the following key functionalities:

• Receives API requests via a secure webhook that requires header-based authentication.
• Generates a dynamic key combining user API key and current time slice (minute and hour) to track usage granularly.
• Increments usage counters in Redis for both per-minute and per-hour periods for each API key.
• Checks if the request count exceeds defined limits (10 per minute and 60 per hour) and blocks further processing if exceeded.
• If under limits, queries Airtable to fetch Pokemon data.
• Formats and returns a message with the current API usage count and the requested data, or a friendly limit-exceeded message if the user goes over their quota.

By automating these steps, Sarah saves hours weekly in manual monitoring and incident handling, reduces server overload, and ensures a fair API experience for all users.

Prerequisites ⚙️

• n8n account with workflow creation access.
• Airtable account with a base containing a Pokemon table and API key credential set in n8n.
• Redis Cloud account with credentials configured in n8n to store and increment request counts.
• HTTP Header Authentication credential in n8n to secure the webhook.

Step-by-Step Guide to Build This Workflow

Step 1: Create and Secure a Webhook Trigger

Open n8n and create a new workflow. Add a Webhook node named Webhook1. Set the path to a unique identifier, for example, a3167ed7-98d2-422c-bfe2-e3ba599d19f1. Configure authentication to “Header Auth” and link it to your pre-created HTTP Header Authentication credentials. This ensures only requests with valid x-api-key headers reach your workflow.
You will see the webhook’s test URL generated; keep this handy for later API requests.

Common mistake: Forgetting to set header authentication leads to unauthorized access or security gaps.

Step 2: Extract and Generate API Rate Limit Keys

Add a Set node named Set connected to the webhook output. Use it to build a string key combining the incoming x-api-key header with the current hour and minute using the expression:
{{$json["headers"]["x-api-key"] +'-'+ new Date().getHours() +'-'+ new Date().getMinutes()}}.
This key represents a unique identifier for per-minute limits.

Expected: The node outputs a JSON object with a field apiKey like user123-14-23 for tracking usage.

Common mistake: Not matching variable names causes downstream nodes to fail.

Step 3: Increment Per-Minute Usage Count in Redis

Add a Redis node named Redis to increment the request count for that apiKey with a TTL (time to live) of 3600 seconds (1 hour) to clear old counts automatically. Choose the incr operation with expiration.
This tracks how many requests have been made in the current minute by a user.

Step 4: Check if Per-Minute Limit is Exceeded

Add an If node called Per minute after Redis. Compare the numeric Redis count for the current per-minute key against the limit 10 using expression:
{{$json[$node["Set"].json["apiKey"]] <= 10} to allow or block requests.

True branch: Continue processing.
False branch: Stop and return a "limit exceeded" message.

Step 5: Generate Per-Hour API Key

Add another Set node named Set2 that concatenates the x-api-key from the header and the current hour only, like:
{{$node['Webhook1'].json["headers"]["x-api-key"] +'-'+ new Date().getHours()}}

This key supports counting requests in the hour regardless of minute.

Step 6: Increment Per-Hour Counter in Redis

Add a Redis node named Redis1 linked to Set2 to increment the hourly usage count.

Step 7: Check if Hourly Limit is Exceeded

Use an If node Per hour to compare the hourly usage count to limit 60:
{{$json[$node["Set2"].json["apiKey"]] == 60}. Branch accordingly.

True branch: Send "You exceeded your limit" message using a Set node Set1.
False branch: Continue to retrieve data.

Step 8: Retrieve Pokemon Data from Airtable

Add an Airtable node to list records from the "Pokemon" table. This fetches all Pokemon data needed for the API response.

Step 9: Format the API Response

Add a Function node that maps the Airtable results into a concise JSON response with the current limit usage message, extracting each Pokemon’s name and URL fields:

const limit = `Limit consumed: `+ $node['Redis1'].json[$node['Set2'].json['apiKey']];
return [{ json: {
  message:limit,
  body: items.map(item => ({
    name: item.json.fields.name,
    url: item.json.fields.url
  }))
}}];

Step 10: Return Limit Exceeded Message for Too Many Requests

On the False paths for limit checks (Per minute and Per hour nodes), use Set nodes to output a "You exceeded your limit" message to inform users politely about quota breaches.

Customizations ✏️

• Change API limits: Adjust the number 10 in the Per minute If node and 60 in the Per hour node to any desired threshold to accommodate different traffic levels.
• Customize data response: Modify the Function node’s JavaScript to include other fields from Airtable or filter specific Pokemons as needed.
• Add detailed error messages: Enhance the Set nodes for limit exceeded to include retry-after headers or estimated reset times.
• Enhance security: Use an additional node to log API keys abusing limits into a database for review and blacklist automation.
• Implement longer duration limits: Add extra Redis keys with daily counts for extended rate limiting periods.

Troubleshooting 🔧

Problem: Redis keys not incrementing correctly

Cause: Incorrect dynamic key naming or missing TTL in Redis node.
Solution: Double-check expressions building the Redis keys in Set nodes to ensure they match exactly the header plus date/time values. Make sure TTL is set to expire keys and prevent indefinite growth.

Problem: Airtable records not fetched

Cause: Airtable API credentials missing or table name misspelled in the Airtable node.
Solution: Verify Airtable credentials in n8n and confirm the table "Pokemon" exists precisely as named.

Problem: Unauthorized webhook access

Cause: No or incorrect HTTP Header Auth on the webhook.
Solution: Configure and apply the correct HTTP Header Authentication credentials to the webhook node.

Pre-Production Checklist ✅

• Verify the webhook is secured using HTTP header authentication and test with a valid x-api-key.
• Test Redis nodes increment counters properly by making test calls simulating API requests.
• Confirm Airtable node can successfully retrieve data.
• Check the correct threshold numbers in If nodes match your intended rate limits.
• Run multiple test requests to cover both acceptance and limit exceeded scenarios.

Deployment Guide

Once tested, activate your workflow by toggling the active switch in n8n. Embed the webhook URL into your API endpoint handlers, ensuring clients include valid x-api-key headers.
Monitor usage via Redis statistics and n8n execution logs to ensure proper rate limiting behavior. You may add alerts for limit breaches via email or Slack using additional nodes.

FAQs

Q1: Can I use another database instead of Redis for counting?
A1: Redis is ideal for fast increments with TTL, but you can use alternatives like Memcached or a SQL database with counters, though performance and complexity vary.

Q2: Are there costs involved with Airtable and Redis usage?
A2: Yes, depending on your Airtable and Redis plan; monitor usage to avoid unexpected charges.

Q3: Is my API key data secure?
A3: This workflow secures webhook access with HTTP header authentication and only uses keys internally for counting; data security depends on your n8n and credential management.

Conclusion

By building this detailed n8n workflow, you can confidently enforce API rate limits using Redis and Airtable, protecting your system from abuse and ensuring a positive user experience. You have automated granular per-minute and per-hour usage tracking and learned how to respond gracefully when limits are exceeded, saving you hours of manual monitoring and frustration.

Consider extending this workflow by adding billing integration for paid API tiers, detailed logging for analytics, or alerting mechanisms to notify admins of overuse. With this foundation, you have a robust and scalable API rate-limiting system tailored to your specific service needs.