diff --git a/.gitignore b/.gitignore
index f9f1d49..e9ff5a6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -13,3 +13,6 @@ _site/
 # Ignore folders generated by Bundler
 .bundle/
 vendor/
+
+# For JetBrains IDEs
+.idea/
diff --git a/Gemfile.lock b/Gemfile.lock
index 8de7c10..8bce6c9 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -13,6 +13,7 @@ GEM
     forwardable-extended (2.6.0)
     google-protobuf (3.24.3-aarch64-linux)
     google-protobuf (3.24.3-arm64-darwin)
+    google-protobuf (3.24.3-x64-mingw-ucrt)
     google-protobuf (3.24.3-x86_64-linux)
     http_parser.rb (0.8.0)
     i18n (1.14.1)
@@ -65,9 +66,14 @@ GEM
     rexml (3.2.6)
     rouge (4.1.3)
     safe_yaml (1.0.5)
-    sass-embedded (1.67.0)
+    sass-embedded (1.67.0-aarch64-linux-gnu)
+      google-protobuf (~> 3.23)
+    sass-embedded (1.67.0-arm64-darwin)
+      google-protobuf (~> 3.23)
+    sass-embedded (1.67.0-x64-mingw-ucrt)
+      google-protobuf (~> 3.23)
+    sass-embedded (1.67.0-x86_64-linux-gnu)
       google-protobuf (~> 3.23)
-      rake (>= 13.0.0)
     terminal-table (3.0.2)
       unicode-display_width (>= 1.1.1, < 3)
     unicode-display_width (2.4.2)
@@ -77,6 +83,7 @@ PLATFORMS
   aarch64-linux
   arm64-darwin-21
   arm64-darwin-23
+  x64-mingw-ucrt
   x86_64-linux
 
 DEPENDENCIES
diff --git a/docs/integrating/httpsync.md b/docs/integrating/httpsync.md
index 7957722..bc75df6 100644
--- a/docs/integrating/httpsync.md
+++ b/docs/integrating/httpsync.md
@@ -18,10 +18,10 @@ The standard pattern for webhooks is:
 1. Something happens in an external system.
 2. The external system sends you an event (usually they send an HTTP POST).
 3. Your backend validates the event is authentic.
-4. Your backend enques the event for further processing, and returns a successful response.
+4. Your backend enqueues the event for further processing, and returns a successful response.
 5. Your backend processes the event further, like synchronizing data from the external service, or updating your own data based on the external event.
 
-The big challenge here is that the order events happen in the external system (first step), and the order your backend processes events (last step), can happen in any order. Both because events from the external system may reach your application in any order, and because your backend may not process them in serial.
+The big challenge here is that the order events happen in the external system (first step), and the order your backend processes events (last step), can happen in any order. Because both events from the external system may reach your application in any order, and because your backend may not process them in serial.
 
 So you could have, for example, have a user's name in an external system that changes from 'Kyle' to 'Taylor'; when you process these events, you either need to know which of them to throw out (this is tricky to build, and not always possible), or you need to re-query the external system for the latest data (which is potentially slow).
 
@@ -52,7 +52,7 @@ Here's how it works:
 
 It's important to note that *you will not need to handle concurrent HTTP Sync webhooks.*
 
-Instead, all processing happens within your API endpoint. Your endpoint can take up to a minute (or more, when [self-hosting](/docs/self-hosting))
+Instead, all processing happens within your API endpoint. Your endpoint can take up to a minute (or more, when [self-hosting]({% link docs/operating-webhookdb/self-hosting.md %}))
 to respond, to make sure you have time to do what you need to with the changed data. The page size can also be modified to send fewer rows.
 
 When your endpoint returns successfully, we assume that page has been processed, so can POST the next page, until there are no new changes. If your endpoint returns an error, we retry the POST until it succeeds.