Makes sense. Two ways of doing this: 1) You let the default sign up API run (which will create a new session), but then you add some

accessTokenPayload

(See https://supertokens.io/docs/emailpassword/common-customizations/sessions/new-session#how-to-store-information-in-a-session) indicating that this user has not beed approved yet. Then on the frontend, for your routes, you can always check this value and in case the user is not approved, you show some screen like "please wait for approval...". Everytime this screen is shown, you also query the backend to confirm that the user is still not approved. In case they are, you modify the

accessTokenPayload

to say that they are approved. On the backend APIs, you create your own middleware which runs after

verifySession

middleware and checks that the user is approved before calling the actual API. If not approved, it returns

403

or something. This way, depending on your session lifetime setting, a user doesn't need to sign in after they are approved. Their existing session would work. 2) You modify the default sign up API to not create a new session. You modify the default sign in API to only allow sign in in case the user is approved (after verifying their credentials). This method would probably be easier to implement, however, it would mean that the user needs to login to know if they are approved or not & if they are approved, they would need to login to get access to the app.