#Multiple requests to the auth endpoints instead of one

8 messages · Page 1 of 1 (latest)

ornate plume
#

I'm using better-auth in my SPA and I'm noticing it's making a lot of requests to the same endpoint although I only make the request one time in my beforeLoad function in TS Router

river frigateBOT
#

Hi @ornate plume. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:

#

You’re not doing anything wrong—this is a known behavior with Better Auth right now.

From the existing discussions:

  • Better Auth currently issues multiple HTTP calls for auth-related work (e.g. get-session, token fetch, internal DB calls), and this can make it look like “many requests” even if you only trigger auth once from your router or beforeLoad logic.[Better Auth slow; 200ms latency]
  • Convex staff have confirmed that:
    • The extra calls are expected with the current component design.
    • Reducing the number and latency of these auth HTTP calls is an active performance priority, but there isn’t a documented way today to collapse them into a single request from an SPA.[Better Auth slow; 200ms latency]

The knowledge sources don’t describe a specific SPA/TS Router pattern that would accidentally multiply calls (e.g. a known bug or misconfiguration), nor a supported way to force Better Auth to use exactly one network request per auth check. Because of that, I can’t confidently point to a concrete fix beyond general debugging (checking that beforeLoad only runs once per navigation, that you’re not creating multiple auth clients/providers, etc.), which isn’t covered in the docs.

#

If you need to optimize further right now, the only documented levers are around SSR and token reuse (e.g. passing an initial token to ConvexBetterAuthProvider in SSR frameworks), but those examples are for Next.js and TanStack Start, not a plain SPA, so they don’t directly apply to your setup.[Initial token]

So in summary:

  • Multiple auth HTTP calls per “logical” auth check are currently expected with Better Auth.
  • There’s no SPA-specific configuration in the docs to reduce them to a single request.
  • Performance improvements here are on the roadmap, but not yet documented as released.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@ornate plume Kapa.ai is still learning and improving, please let me know how I did by reacting below.

ornate plume
#

@river frigate is it normal that even if the user is idle in a page, it keeps hitting the server multiple times?

river frigateBOT
#

Let me check the knowledge base for you again. One moment! :books:

#

It can be normal to see repeated auth-related requests even when the user appears “idle,” but the exact pattern depends on what is being called.

From the available info:

  • Better Auth + Convex currently makes multiple HTTP calls for auth (e.g. get-session, token/JWT endpoints, internal DB calls), and this is expected with the current implementation. Users have reported “a lot of requests” to auth endpoints even when they only trigger auth once, and Convex staff confirmed this is known and that performance improvements are a priority.[Better Auth slow]
  • Separately, the Convex client itself will proactively refresh auth tokens shortly before they expire (default 10 seconds before expiry), which can also generate periodic auth traffic even without user interaction.[Client options]

What the sources do not clearly document is:

  • The exact frequency/pattern of Better Auth’s session checks in a SPA when the user is idle.
  • A configuration switch to fully stop background auth calls while a page is open.

So:

  • Some background auth traffic while “idle” is expected today (session checks, token refresh).
  • If you’re seeing very frequent or seemingly continuous calls, that might be abnormal, but the docs don’t provide enough detail to say what rate is “too much” or how to tune it in a SPA.

If you can, capturing a short network trace (which endpoints, how often) and sharing it in Discord would be the next step to determine whether what you’re seeing is within the current expected behavior or a bug.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: