We are seeing tons of errors with the following pattern: multiple successful authentication requests with the same SessionTokenHash in a row as we go through our auth user flow and then suddenly 404 session_not_found.
This is all happening within seconds.
It is happening frequently but seemingly randomly. Some users never ever see it. And others are completely blocked.
Our user lock TTL is 3600 seconds. Our customers are frustrated. We are baffled. Please help!
Hi Monica,
Thanks for posting! I just responded to your message in our Community Slack as well, where I see a colleague of yours is currently responding.
I’ll continue the conversation there in order to consolidate comms!
Pasting the resolution from Slack below for posterity!
It looks like what’s happening is that:
The Session is initially created via a PasswordCreate call - creates SessionA
A second OTP factor is then added to the Session - the response includes SessionB
This causes Session A to “roll”
When a new factor is added to an existing Session, the existing Session is set to expire in one minute. This is for security purposes so that the old Session with only one factor can no longer be used.
The fix here is to grab the newsession_token / session_jwt from the OTP Authenticate response in step 2 (SessionB), and update the Session token/JWT in your application with the new value.
I am currently seeing the same thing, however, I don’t believe that another factor is being added, because when I inspect the newly minted session the only difference compared the previous session are the fields: exp, iat, nbf, last_accessed_at.
Similar behavior to OP where requests are bursting, for me its against against the stytch.sessions.authenticateJwt endpoint. Currently my max_token_age_seconds is 60 minutes, so I wouldn’t expect that I could reproduce this frequently, but I can.
Hey @Devin_Otway ,
Could you please share any request_ids for where you’re seeing this occur? We’d be happy to take a closer look.
Generally speaking, there are a few edge cases where Stytch will automatically revoke a session - generally either for security reasons, or because a user was deleted, etc.
|
| Column 1 | B |
|---|---|
| requestId | status |
| request-id-test-0cc83e5a-ca84-4110-8b9a-945e7e54ec8c | Error |
| request-id-test-3ccd24f0-9a13-4e33-8900-2916f9aa1a16 | Error |
| request-id-test-c950642d-2d1c-4abe-9479-dfe2c16f6314 | Error |
| request-id-test-1b9d2a8b-a057-428e-85bc-4fa1ffb6e49d | Success |
| request-id-test-a93a1884-bfea-4b53-b369-0dd33d991d1f | Success |
| request-id-test-7cbc8b38-ee99-4903-98ea-fd12fd9f2c99 | Success |
| request-id-test-76811747-ea0e-437f-8c3b-9c33eddbe857 | Error |
| request-id-test-6ed0c1d8-6dc1-421f-bcdd-56a313fc2c94 | Error |
| request-id-test-f681f215-9bd4-4afc-bb8c-ac125234fa6d | Error |
I think this is whats happening in my case. I have an SSR server that makes a bunch of concurrent requests and then one of the auth requests triggers a refresh of a token (for unknown reason), then subsequent requests fail until client gets refreshed token
Thanks for sharing these request IDs!
Taking a look, this looks to be a different issue than the one originally described in this thread.
For example, for request-id-test-a93a1884-bfea-4b53-b369-0dd33d991d1f, this corresponds to a Session that was started at 2025-10-17T18:40:13Z, and the same Session gets continually re-authenticated afterwards.
It gets last accessed at 2025-10-17T19:13:34Z, when it appears to be authenticated with the Stytch API with a session_duration_minutes of 60, then is last re-authenticated at 2025-10-17T19:43:21Z (without extending its lifetime), where finally, it never gets revoked and expires at 2025-10-17T20:13:34Z.
We did notice however, that between the successful MultiTenantSessionsAuthenticate calls there are consistent errored ones with an invalid Session JWT passed in, resulting in session_not_found errors.
How are you handling the session cookies in your frontend? It might be worth adding some logging to check that there’s not any weird caching going on with old/expired session tokens being passed into your API calls as it doesn’t look like the concurrent requests use the same token consistently (resulting in some 200s and some 404s throughout).
It looks like you may be using the Node SDK; it may help to also keep these considerations in mind: Stytch and backend development | Stytch B2B authentication
