@workos/mcp-docs-server 0.1.0 → 0.2.0

package/.docs/organized/docs/events/data-syncing/events-api.mdx

@@ -1,12 +1,12 @@
 ---
-title: "Sync data using the events\_API"
-description: "A step-by-step guide on how to start syncing data using the\_API."
+title: Sync data using the events API
+description: A step-by-step guide on how to start syncing data using the API.
 originalPath: .tmp-workos-clone/packages/docs/content/events/data-syncing/events-api.mdx
 ---
 
 ## What you’ll build
 
-In this guide, we will walk you through what you will need to integrate with the [events API](/reference/events):
+In this guide, we will walk you through what you will need to integrate with the [events API](/reference/events):
 
 - Create a _cursor_ for use with the events API
 - Update your cursor

package/.docs/organized/docs/events/data-syncing/index.mdx

@@ -33,8 +33,7 @@ Your app can consume events from WorkOS via either the events API or webhooks.
       "department": "Engineering",
       "job_title": "Software Engineer"
     },
-    "role": { "slug": "member" },
-    "raw_attributes": {}
+    "role": { "slug": "member" }
   },
   "created_at": "2023-04-28 20:05:31.093"
 }
@@ -56,7 +55,7 @@ With webhooks, WorkOS automatically notifies your app when an event occurs by in
 
 ## API vs. webhooks
 
-Depending on your constraints, you may want to use the events API or webhooks. Here is a comparison of the two:
+We recommend using the Events API instead of webhooks to keep your data in sync—especially for [user](/events/user) and [directory](/events/directory-sync) events. With the Events API, you control how often and how much data you ingest. Webhooks, on the other hand, require your endpoint to handle unpredictable spikes in event volume, which can make them harder to manage at scale. That said, webhooks may still be the better fit depending on your use case. Here’s how the two compare:
 
 | Aspect         | Events API                                                                | Webhooks                                                                        |
 | -------------- | ------------------------------------------------------------------------- | ------------------------------------------------------------------------------- |

package/.docs/organized/docs/events/data-syncing/webhooks.mdx

@@ -54,9 +54,9 @@ In order to avoid unnecessary retry requests hitting your webhook handler, we re
 
 ### Respond with HTTP 200 OK
 
-On receiving an event, you should respond with an `HTTP 200 OK` to signal to WorkOS that the event was successfully delivered. Otherwise, WorkOS will consider the event delivery a failure and retry up to 12 times, with exponential backoff over 3 days. You do not need to signal to WorkOS whether or not the event was processed successfully.
+On receiving an event, you should respond with an `HTTP 200 OK` to signal to WorkOS that the event was successfully delivered. Otherwise, WorkOS will consider the event delivery a failure and retry up to 6 times, with exponential backoff over 3 days. You do not need to signal to WorkOS whether or not the event was processed successfully.
 
-### (A) Validate the requests using the SDK
+### (A) Validate the requests using the SDK
 
 Before processing the request payload, verify the request was sent by WorkOS and not an unknown party.
 
@@ -140,11 +140,11 @@ If you would like to test against your local development environment, we recomme
 
 ### Respond to events immediately
 
-To avoid webhook requests potentially stressing your system, WorkOS strongly recommends that you respond to a webhook request with a 200 OK response as quickly as possible once received.
+To avoid webhook requests potentially stressing your system, WorkOS strongly recommends that you respond to a webhook request with a 200 OK response as quickly as possible once received.
 
 If you process the event before responding, your system may not be able to handle a spike of requests. This may cause requests to timeout and result in missing important updates.
 
-A common pattern is to store the request payload on a message queue, respond with a 200 OK response, and use a background worker to process the messages in the queue.
+A common pattern is to store the request payload on a message queue, respond with a 200 OK response, and use a background worker to process the messages in the queue.
 
 ### Recover from failed events