Merge pull request #792 from kohasummons/patch-1

docs: fix typo in recipes.mdx

Author: rishabhpoddar

v2/contribute/architecture/recipes.mdx

@@ -9,20 +9,20 @@ A recipe is one independent auth module that can be consumed "as is". It can be
 
 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:
+Other examples of recipes are:
 - email password login (auth recipe)
 - social login (auth recipe)
 - email verification
 - 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 can also be combined 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
+- For website navigation, the 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.
+    - 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.