Base44 429 errors — "rate limit exceeded"

Sixty seconds, no AI. Most people are fixed by one of these and never need the prompt below.

1. 1

   Check status.base44.com before you debug your own code. In September 2026 a builder was told by support that connection failures came from "a temporary platform-wide tightening of read and write limits, put in place during database infrastructure work", which "applies the same way across every plan". Four days of debugging your own app is a waste if it is the platform.

2. 2

   Ask whether it happens with one user or many. Base44's limits are per person, so capacity grows with your user count. A 429 with a single user is almost always a loop in your own code.

3. 3

   Find the polling. Anything on a setInterval, any list that auto-refreshes, any search box that queries on each keystroke without a debounce, any component that re-fetches on every render. This is the cause most of the time.

4. 4

   Look at your bulk operations. An import, a migration or a "fix all" button firing one write per row will hit the write ceiling fast — and those ceilings do not move.

5. 5

   Do not upgrade to fix it. Most limits scale with plan (Free/Starter 1×, Builder 2×, Pro 3×, Business/Elite 5×, Enterprise 10×) — but the three entity write endpoints do not. Base44's docs: "Three entity write endpoints are an exception to that scaling. Their limits are the same on every plan, including Enterprise."

6. 6

   Know the numbers you are actually up against. Create 140 requests/min. Update 100/min. Delete 100 per 30 seconds. List and Count share a single 100/min budget — so a page that lists and counts on load spends twice what you think.

Most 429 advice on the internet is generic — back off, retry, upgrade. Two things make Base44 different, and both change what you should do.

The write ceilings are fixed. Create, update and delete on entities are capped identically on every plan, Enterprise included. On most platforms "we hit the rate limit" is answered with a bigger plan. Here it is not, so a bulk import, a batch fix or a write-per-row migration has to be paced in your code. There is no amount of money that makes this go away.

List and Count share one budget. They draw on the same 100 requests per minute. A dashboard that renders a list and a total on the same load is spending double, and it is the single easiest accidental doubling to introduce.

And because limits are per person rather than per app, the shape of the problem inverts as you grow: with one user, a 429 means your code is looping. With a thousand users, a 429 means your per-user request pattern was always too heavy and you have only just noticed. The fix is the same — fetch less — but the urgency is not.

Worth separating two things that get confused constantly: rate limits are requests per minute against the API. Credits are what the AI builder consumes while writing your app. They are unrelated. Almost every search result and video about "Base44 limits" is about credits.

Paste into your Base44 builder chat. The first one only reads — it changes nothing, so it is safe to run on a live app.

Audit this Base44 project for what is generating too many API requests. I am
getting 429 rate-limit errors.

READ ONLY. Do not edit, create or delete any file. Do not run any build. If
something should change, describe it — do not do it.

EVIDENCE RULE — this governs everything below.
Every finding must carry one of:
  [CODE]        a file path and line number
  [LIVE]        a URL you fetched, with the HTTP status code you received
  [UNVERIFIED]  you could not check it from here
No finding without one. Do not guess at request volumes you have not counted,
and do not report something as fine because it looks conventional.

THE LIMITS YOU ARE AUDITING AGAINST
Entity writes, identical on EVERY plan including Enterprise:
  create 140/min · update 100/min · delete 100 per 30 seconds
List and Count SHARE one 100/min budget.
…

Using the audit you just produced, implement the fixes. The audit was read-only;
this turn is the only one that writes.

Order, highest requests-per-minute first:
  P0  anything polling on a timer that does not need to
  P0  any retry loop with no backoff
  P1  duplicate fetches of the same entity on one screen
  P1  list plus count on the same screen where one would do
  P1  un-debounced search inputs
  P2  pagination and limits on unbounded lists

For each fix, prefer in this order:
  1. Do not fetch at all — is the data already in memory?
  2. Fetch once and cache — raise staleTime, drop refetchOnWindowFocus
  3. Fetch on demand — on user action rather than on a timer
  4. Fetch less often — longer interval, debounce at 300-500ms
  5. Only then, batch and back off

…

Verify the request volume actually came down. Do not trust the previous turn's
estimate.

PART 1 — COUNT WHAT IS LEFT
Re-read the project and list every remaining source of automatic requests:
timers, refetch intervals, focus refetches, retry loops. For each, give the file,
the line and the interval. If the list is not shorter than it was before the fix,
say so plainly.

State the new estimated requests per minute for one user on the busiest screen,
with the arithmetic, and compare it to the figure the fix turn claimed. Where
they disagree, your recount wins.

PART 2 — THE BULK-WRITE TEST
For any import, migration or batch operation, state how long it now takes for
1,000 records at 140 creates or 100 updates per minute, and confirm it stops
rather than retries when it receives a 429. Quote the code that does that.

…

• Base44 — Apps API rate limitsThe actual numbers, and the three write endpoints that do not scale with plan.
• Base44 — Monitoring API rate limits50 req/min on most endpoints, 75 on Get user. Separate budget.
• Base44 — troubleshootingThe platform's own list, including the full HTTP status code table.
• Base44 status pageCheck this before you debug your own code. Platform-wide tightening has happened.