Hello, why does signup respond with a 200 in case an email already exists?

Hey! Good question. This has got to do with distinction of error types: 1) User, expected errors (yielding 200 response) 2) Unexpected errors Essentially, (1) is a valid user flow that results in a non successful response. But it's still a valid user input, so you want to display some UI to the user explaining what just happened Whilst (2) is asomething like the db going down (500 http code), or a bad input (required input fields in JSON body missing - 400 response) etc..

Ok so i got the same when forgetting to input email to the /signup

well, cause in this API, the input is of type formField: [{id: string, value: string}]. If you call it without the formField array, it will give back 400

Is there a way to change this?

Yes. There is, but it would require you to override the API and return your own response. Checkout the advanced customisation section of the recipe docs.

I see your point although i would expect to have an API with a documentation that shows me which routes are available

> i would expect to have an API with a documentation that shows me which routes are available You can see the schema of the response in the swagger docs which shows you all the possible outputs.

Usually request libraries like Axios etc. throw an exception when a 4xx or 5xx error responds. In this case it wouldn't happen so you always have to test the body instead of relying to "WORKED", "DIDNT WORK"

Yea. And that's intentional. Cause if a wrong credential error gave a 400 response, axios would throw an error, and people would end up displaying a generic "something went wrong" message. As opposed to here, where we are forcing people to check the status type and so they know the different types of messages that they need to show to the end user.

But you could simply respond a 400 or 401 with the same body?

it can be caught and the body read. But in my exp, several people forget to read the body after catching.. people even forget to catch several times.

So i don't need to do this: check if status is "OK", then read the rest If not "OK" show an error

well.. if you do not like this, you can override the backend APIs and send your own responses 🙂

Ok sure it's up to you 🙂

it is debatable. I agree.

So you meant this? https://supertokens.com/docs/emailpassword/advanced-customizations/apis-override/custom-response/api-override

yes

Ok i see also here: "This feature is only applicable for users who build their own frontend since our frontend requires on a specific output"

axios interceptor doesn't care about these APIs. It's only meant for session management related tasks.

Ok but what about automatic refreshing of the token. That is only supported via the SDK right?

Yes. Correct. We have a vanilla JS SDK that you can use with your custom UI for that

I see, thanks for the help

happy to help 🙂 Thanks for checking out SuperTokens!