← All questions

295 API scenarios fail with QUOTA_EXCEEDED: Exceeded quota for verifying passwords

Error: Firebase sign-in failed for qa-member@example.com:
  QUOTA_EXCEEDED : Exceeded quota for verifying passwords.

4 answers

• 48votes✓

  Accepted answer

  Not one that ships working today, no. You are going to have to cache it yourself, and the good news is that it is a small change with a very large effect.

  The shape of the problem: that step performs a fresh password sign-in for every scenario. Identity Platform rate-limits password verification per project, so with several hundred @api scenarios you are making several hundred verifications against one project from one IP within a few minutes, and you exhaust the quota partway through. Everything after that fails at sign-in, before any assertion runs. Because it is time-dependent it looks exactly like flake — a scenario that fails at minute twenty passes alone — which is how this gets closed as "flaky" and comes back.

  An ID token from that endpoint is valid for an hour. Cache one per role, keyed the way the UI auth cache is, with a TTL comfortably under the hour — 45 minutes matches the auth.maxAgeMinutes the UI side already uses for the same reason. That turns several hundred sign-ins into one per role.

  Until you have it, keep API runs single-worker and single-browser so you are at least not multiplying the rate, and be aware that a run in this state tells you almost nothing about your API surface. The scenarios that passed are the ones that ran before the quota went.

  PVanswered by Priya Venkateshmaintainer29,604 · 15 Apr 2026

  Reply
• 31votes

  Worth knowing that the mechanism which should make Priya's answer unnecessary already ships, and does nothing.

  sdods auth capture writes a token file per role and index:

  textCopy

  projects/<slug>/.auth/staging/owner-0.token.json
  projects/<slug>/.auth/staging/admin-0.token.json
  projects/<slug>/.auth/staging/member-0.token.json

  Those files are on your disk right now and they contain what the API layer needs. Nothing reads them at runtime, and auth.tokenPlacement has no consumer either. That is the open issue — the capture side is written, the consumption side is not — and it is why every project that hits this ends up hand-rolling the cache instead of using the framework's own path.

  So: build the cache, but build it so you can delete it later.

  DOanswered by Daniel Oyelaranmaintainer24,177 · 16 Apr 2026

  Reply
• 16votes

  Please also check what else lives on that identity project before you keep running into the limit. Quota exhaustion is per project, not per caller — if anything real signs in against the same project as your staging fixtures, your test suite can lock out actual people for the rest of the window. We moved the fixtures onto their own project partly for that reason and partly so the noise in the sign-in metrics stopped being ours.

  RHanswered by Rasha Halabi572 · 17 Apr 2026

  Reply
• 9votes

  Small addition to the cache: handle the failure as well as the success. Backoff-and-retry specifically on QUOTA_EXCEEDED turns a cliff into a slope, so if the cache misses in a burst (new role, expired TTL, whatever) you degrade instead of losing the rest of the run. Ten lines, and it saved us a rerun the first week it existed.

  SKanswered by Sunita Kale982 · 24 Apr 2026

  Reply

Have a different question? Ask it.