How we processed 60,000 records through an API in Bubble (no recursion, no backend workflows)

[SAIDER1]

Most Bubble apps break the moment you try to process large lists.

You hit:

• API limits (100 items per request)

• Recursive workflows

• Backend scheduling chains

• Timeouts and fragile logic

We ran into this exact problem with a client:

~60,000 records

External API allowed max 100 items per request

Needed reliability, retries, and visibility

So we built Batchy Runner.

Use case:

Instead of looping workflows or scheduling backend jobs, Batchy Runner:

• Splits large lists into safe batches (e.g. 100 items)

• Sends requests sequentially from the browser

• Respects rate limits with configurable delays

• Retries failed batches automatically

• Exposes progress, current batch, and completion events

• Works entirely client-side

Result

60,000 records processed cleanly

No recursive workflows

No backend scheduling

No crashes

Full progress tracking in the UI

What surprised us most

The solution wasn’t “more backend logic”.

In Bubble, performance at scale often comes from processing smarter before you overload workflows or the database.

If you’re dealing with:

• Large lists (10k–100k+)

• APIs with strict request limits

• Imports, syncs, or bulk operations

Batchy Runner changes what’s possible — without making your app fragile.

Demo

Editor

[boston85719]

Help Needed: Processing 60,000 Records via API with 100-Record Limit

The Problem: I have an external API that returns employee records, but it’s limited to 100 records per request. I need to fetch and process approximately 60,000 records in total. The API uses a cursor parameter for pagination. What I Need: A recursive workflow in Bubble that: Fetches records in batches of 100 using the cursor parameter. Processes each batch (e.g., saves records to the database). Automatically fetches the next batch by incrementing the cursor until all records are ret…

Bubble verified and approved that Plugin at Hyper Speed.

Does the plugin expose api keys client side when running, either for the API provider fetching from or the bubble app saving to DB?

[SAIDER1]

Batchy Runner does not expos or log your keys on its own, and it does not save anything to Bubble’s database. However because it runs in the user’s browser, any headers you send (including API keys or tokens ) are accessible via browser dev tools, exactly the same as Bubble’s built-in API Connector (client-side) or any frontend JS.

If your API requires a secret key that mus never be exposed , the correct pattern is still to proxy through a backend endpoint. Batchy Runner is ideal for APIs that are designed to be called client-side (scoped tokens, public keys, user-level auth…).

[boston85719]

@SAIDER1

does not save anything to Bubble’s database

What are you doing with processed data, just keeping it in browser or saving to bubble db?

[SAIDER1]

Batchy Runner processes everything in the browser only and sends it to the external API. It does not write to the Bubble database, and it does not persist results unless the developer explicitly chooses to do so in workflows. The only thing optionally exposed is last_response, which is meant for debugging or inspection and is overwritten on each batch. If a dev wants to save results to Bubble, they do it intentionally in a “Batch Success” or “Batch Finished” workflow . nothing is saved automatically or implicitly.