Rate limiting in Bubble involves tracking API call counts per user within a time window and blocking requests that exceed the threshold. You create a Data Type to log API calls, count recent entries before each call, and conditionally block or allow the request. This tutorial also covers handling rate limit responses (429 errors) from external APIs you call via the API Connector.
Overview: Rate Limiting in Bubble
This tutorial covers two aspects of rate limiting: protecting your own Bubble app from API abuse by users, and handling rate limit responses from external APIs you connect to. You will build a call-counting system, enforce limits via workflow conditions, and implement retry logic for external API 429 errors.
Prerequisites
- A Bubble app with API Connector configured for external API calls
- Understanding of backend workflows and scheduling
- Familiarity with Bubble's conditional workflow logic
- An external API that enforces rate limits (for the handling portion)
Step-by-step guide
Create a Data Type to track API call logs
Create a Data Type to track API call logs
In the Data tab, create a new Data Type called 'APICallLog'. Add fields: 'user' (User), 'endpoint' (text — which API was called), 'timestamp' (date — when the call was made), 'status' (text — success/failure/rate_limited). This log lets you count how many calls a user has made within any time window.
Expected result: An APICallLog Data Type exists to record every API call with user, endpoint, time, and status.
Count recent calls before allowing a new request
Count recent calls before allowing a new request
Before making any API call in your workflow, add a search step: 'Do a search for APICallLogs' where user is Current User, endpoint is the target API name, and timestamp is greater than 'Current date/time minus 1 hour' (or your desired window). Count the results. Add a condition on the API call action: 'Only when' the count is less than your limit (e.g., 60 calls per hour). If the count exceeds the limit, show an error message to the user instead of making the call.
Pro tip: For frequently called APIs, consider storing the count on the User record and incrementing it in each call, resetting it with a scheduled backend workflow every hour. This avoids expensive search queries.
Expected result: API calls are blocked when the user has exceeded the rate limit within the time window, with an error message displayed.
Log each API call after execution
Log each API call after execution
After every successful (or failed) API call, add a workflow step to create a new APICallLog record. Set user to Current User, endpoint to the API name, timestamp to Current date/time, and status to 'success' or 'failure' based on the response. This maintains an accurate count for rate limiting and provides analytics on API usage patterns.
Expected result: Every API call creates a log entry that feeds into the rate limiting count for future requests.
Handle 429 rate limit responses from external APIs
Handle 429 rate limit responses from external APIs
When calling external APIs via the API Connector, the API may return a 429 (Too Many Requests) status. In the API Connector settings, check 'Include errors in response and allow workflow actions to continue'. This prevents the workflow from stopping on errors. After the API call action, add a conditional step: 'Only when Result of step X's status_code is 429' — schedule a retry using 'Schedule API Workflow' with a delay. Start with a 5-second delay and double it on each retry (exponential backoff).
Expected result: Your app gracefully handles external API rate limits by retrying after a delay instead of failing permanently.
Build a backend retry workflow with exponential backoff
Build a backend retry workflow with exponential backoff
Create a backend API workflow called 'retry_api_call'. Add parameters: 'endpoint' (text), 'payload' (text), 'retry_count' (number), 'user_id' (text). In the workflow, make the API call. If the response is still 429 and retry_count is less than 5, schedule another retry_api_call with retry_count + 1 and delay = 5 seconds * 2^retry_count. If retry_count reaches 5, log the failure and optionally notify the user or admin that the API is unavailable.
Expected result: Failed API calls are retried with increasing delays, up to a maximum of 5 attempts before logging a permanent failure.
Clean up old API call logs with a scheduled workflow
Clean up old API call logs with a scheduled workflow
To prevent the APICallLog table from growing indefinitely, create a scheduled backend workflow that runs daily. Search for APICallLogs where timestamp is less than Current date/time minus 7 days (or your retention period). Delete these records in a recursive workflow that processes batches of 50-100 at a time. This keeps your database lean and your rate limiting searches fast.
Expected result: Old API call logs are automatically deleted on a regular schedule, keeping the database clean.
Complete working example
1RATE LIMITING — WORKFLOW SUMMARY2==================================34DATA TYPE: APICallLog5 user (User)6 endpoint (text)7 timestamp (date)8 status (text: success/failure/rate_limited)910INBOUND RATE LIMITING (your app):11 Before API call:12 Count = Search APICallLogs13 user = Current User14 endpoint = 'target_api'15 timestamp > Current date/time - 1 hour16 Only when Count < 60:17 Make the API call18 Create APICallLog (status: success)19 When Count >= 60:20 Show error: 'Rate limit exceeded. Try again later.'21 Create APICallLog (status: rate_limited)2223OUTBOUND 429 HANDLING (external APIs):24 API Connector: Check 'Include errors in response'25 After API call:26 When status_code = 429:27 Schedule retry_api_call28 delay = 5 seconds29 retry_count = 13031BACKEND: retry_api_call32 Parameters: endpoint, payload, retry_count, user_id33 Step 1: Make API call34 Step 2 (when 429 and retry_count < 5):35 Schedule retry_api_call36 delay = 5 * 2^retry_count seconds37 retry_count = retry_count + 138 Step 3 (when retry_count = 5):39 Log permanent failure, notify admin4041CLEANUP (daily scheduled):42 Search APICallLogs where timestamp < 7 days ago43 Delete in batches of 50Common mistakes when implementing Rate Limiting for API Calls in Bubble
Why it's a problem: Counting API calls with a client-side search instead of server-side
How to avoid: Implement rate limiting in backend workflows where users cannot manipulate the logic
Why it's a problem: Not cleaning up old APICallLog records
How to avoid: Create a daily scheduled backend workflow that deletes logs older than your retention period
Why it's a problem: Retrying 429 errors immediately without backoff
How to avoid: Implement exponential backoff starting at 5 seconds and doubling each retry
Best practices
- Store rate limit counts on the User record for frequently checked endpoints to avoid expensive searches
- Implement rate limiting in backend workflows for security, not just frontend
- Use exponential backoff for retrying external API 429 errors
- Clean up API call logs regularly to maintain search performance
- Set different rate limits for different API endpoints based on their cost and sensitivity
- Display remaining call count to users so they can pace their usage
- Log rate-limited requests separately for monitoring and alerting
Still stuck?
Copy one of these prompts to get a personalized, step-by-step explanation.
I'm building a Bubble.io app that calls the OpenAI API. I need to limit each user to 20 API calls per hour and handle 429 rate limit errors from OpenAI with retry logic. How should I set this up?
Add rate limiting to my app's AI feature. Track how many times each user calls the OpenAI API per hour. Block requests if they exceed 20 per hour and show a message. If OpenAI returns a 429 error, retry with increasing delays up to 5 attempts.
Frequently asked questions
Does Bubble itself have rate limits on its Data API?
Yes. Bubble's Data API has a rate limit of approximately 1,000 requests per minute per app. If you exceed this, Bubble returns a 429 error.
Can I set different rate limits for different user roles?
Yes. In your rate limiting workflow, use different thresholds based on the user's role or plan. For example, free users get 20 calls/hour while premium users get 100.
How much WU does the rate limiting system itself consume?
Each rate limit check costs about 0.2-0.5 WU for the search, plus 0.5 WU for creating the log entry. For most apps, this is negligible compared to the API call itself.
Should I use a sliding window or fixed window for rate limiting?
The tutorial uses a sliding window (last 60 minutes from now). Fixed windows (reset at the top of each hour) are simpler but allow burst traffic at window boundaries. Sliding windows are more accurate.
Can RapidDev help implement API rate limiting and usage management?
Yes. RapidDev can build comprehensive API management systems including rate limiting, usage analytics, billing integration, and abuse detection for your Bubble app.
Talk to an Expert
Our team has built 600+ apps. Get personalized help with your project.
Book a free consultation