important

This is a contributors guide and NOT a user guide. Please visit these docs if you are using or evaluating SuperTokens.

Core Logic

1) If an API spans across recipes (like get user count or delete user), those should not have a /recipe prefix, and should go in the Storage.java interface.
2) Wherever possible, plugin interface user objects should be directly sent as API response. If you want to hide a property from a response, use the transient keyword like public transient final String passwordHash;
3) Recipes' APIs SHOULD NOT interact with other recipes (unless it's a MUST). Interaction across recipes should happen via the backend SDK APIs. For example, in thirdparty sign up, we also mark the email as verified (depending on the OAuth provider). This should be done in the backend SDK's API for sign up / in and not in the core. See https://github.com/supertokens/supertokens-core/issues/295 for an example. For APIs like delete user or get user count (Auth recipe APIs), which have to interact across several auth recipes (like emailpassword, thirdparty...), this is OK.
4) About input validation:
- a) User input (like email / password / name etc..) should not be validated in the core, and only in the backend SDK. This is because we provide methods in the backend SDK to override how validation for user facing input works, and if a custom validator is provided, that will not be reflected in the core - which might cause issues.
- b) Input that is generated by the core (like access tokens, UUIDs for auth recipes etc..) can be validated - since the validation logic for those cannot be modified by the user.
5) About input normalization: If the input is a user defined input (like email, name etc), those need to be normalized in the backend SDK level, inside the recipe functions. This is because we should allow the developer to override how normalization works. See (12) in this page