Spelling fixes in documentation

docs/api/writing.md

@@ -153,7 +153,7 @@ similar way to our ```POST``` example.
 
     <p>It's advisable to create a separate trigger for <code>UPDATE</code> and <code>INSERT</code>
     avoiding conditionals that decide which is the trigger current operation.
-    This makes it easier to change code for (or even disable) one operation without intefering with others while
+    This makes it easier to change code for (or even disable) one operation without interfering with others while
     improving readability.
     </p>
 </div>
@@ -186,7 +186,7 @@ basic field replacements, and not at all "incorrect."
 * ❌ Cannot be cached or prefetched
 * ✅ Idempotent
 
-Simply use the `DELETE` verb. All recors that match your filter
+Simply use the `DELETE` verb. All records that match your filter
 will be removed. For instance deleting inactive users:
 
 ```HTTP

docs/examples/external_auth.md

@@ -43,7 +43,7 @@ ALTER TABLE users ADD role text NOT NULL DEFAULT 'customer';
 ```
 
 Besides the main user that PostgREST uses to connect to PostgreSQL
-and the anonymous user, we will need two aditional roles for our example:
+and the anonymous user, we will need two additional roles for our example:
 
 * admin - to be used by users that access all the system rows.
 * customer - to be used when user has restricted access to database rows.

docs/examples/users.md

@@ -8,12 +8,12 @@ a username and password system on top of JWT using only plpgsql.
 Future examples such as the multi-tenant blogging platform will use
 the results from this example for their auth. We will build a system
 for users to sign up, log in, manage their accounts, and for admins
-to manange other people's accounts. We will also see how to trigger
+to manage other people's accounts. We will also see how to trigger
 outside events like sending password reset emails.
 
 Before jumping into the code, a little more about how the tokens
 work. Every JWT contains cryptographically signed *claims*. PostgREST
-cares specificaly about a claim called `role`. When a client includes
+cares specifically about a claim called `role`. When a client includes
 a `role` claim PostgREST executes their request using that database
 role.
 
@@ -294,7 +294,7 @@ where actual.role = member_of.rolname;
   -- is equal to email so that user can only see themselves
 ```
 
-Using this view clients can see themeslves and any other users with
+Using this view clients can see themselves and any other users with
 the right db roles. This view does not yet support inserts or updates
 because not all the columns refer directly to underlying columns.
 Nor do we want it to be auto-updatable because it would allow an escalation