important

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

Recipes

A recipe is one independent auth module that can be consumed "as is". It can be consumed by users in their app, or by other recipes.

For example, the session recipe can be used as is in an app to provide it session management, but it is also used by other recipes (like emailpassword / thirdparty / emailverification) in sign in / up APIs or to know if a user is logged in on the frontend.

Other examples of recieps are:

email password login (auth recipe)
social login (auth recipe)
email verificaiton
password reset

Some recipes create users (auth recipes), whilst others work with already created users.

Recipes can also be combined together to build "super recipes". For example, we can combine emailpassword & thirdparty recipe to build thirdpartyemailpassword recipe. This way, we can provide the end user both options of Open ID connect / social login & email password login.

Recipes usually span across the frontend SDK, backend SDK and the core. In each of these layers, the recipe being used is identified by a recipe ID. For example, the session recipe's RID is session.

Different parts of SuperTokens identify recipes using different methods. For example:

For website navigation, th recipe ID is part of the query param of the URL
- The same website path can show different UIs based on the recipe being used. For example, /auth?rid=emailpassword will show the email password login, whereas /auth?rid=thirdparty will show the social login UI.
For API calls (backend or to the core), the recipe ID is a header in the request with the key rid.
- The same API path & method can behave differently depending on the recipe being used. For example, the email password recipe can have a /signin POST API, which behaves differently that /signin POST of the magic links recipe. The backend SDK can know which behaviour to execute based on the rid header in the request.