--FusionAuth/fusionauth-issues#1812

Documentation updates for APIs related to webhook changes.

Author: robfusion

site/docs/v1/tech/events-webhooks/writing-a-webhook.adoc

@@ -18,7 +18,8 @@ Additional headers may be added to the request by adding headers to the Webhook
 * <<Configuration>>
 ** <<Application Scoped Events>>
 ** <<Tenant Scoped Events>>
-** <<Example Configuration>>
+** <<Example Configuration Before 1.37.0>>
+** <<Example Configuration After 1.37.0>>
 * <<Retries>>
 ** <<Retry Examples>>
 * <<Calling FusionAuth APIs In Webhooks>>
@@ -36,7 +37,9 @@ Then, configure the Tenant to listen for the event by navigating to [breadcrumb]
 
 If you have multiple Webhooks configured for a single Tenant, the transaction setting for the event will dictate if FusionAuth will commit the transaction or not.
 
-If you have multiple tenants listening for the same event, they will all receive that event and can filter on the provided [field]#tenantId# to determine if they should handle the event.
+As of version 1.37.0 if you have multiple tenants listening for the same event, they will only receive the events for that tenant, but not for other tenants.
+
+Prior to version 1.37.0 if you have multiple tenants listening for the same event, they will all receive that event and can filter on the provided [field]#tenantId# to determine if they should handle the event.
 
 === Application Scoped Events
 
@@ -52,7 +55,7 @@ As of version 1.37.0, all events can be tenant scoped except instance events:
 
 If you want to get events for certain applications, the preferred method is to send events for a tenant. Filter on the `applicationId` when consuming the event and discard events from any applications not of interest.
 
-=== Example Configuration
+=== Example Configuration Before 1.37.0
 
 Here's an example scenario. You have two tenants, Pied Piper and Hooli. You have configured two webhooks listening for `user.create` events. One updates a separate user database, the other records information in an analytics system. Both the Pied Piper and Hooli tenants have the `user.create` event enabled in their webhook configurations. 
 
@@ -64,6 +67,16 @@ If you are separating your staging and production environments using tenants, we
 
 Please review this issue for additional information about https://github.com/FusionAuth/fusionauth-issues/issues/1543[future webhook improvements].
 
+=== Example Configuration After 1.37.0
+
+Here's an example scenario. You have two tenants, Pied Piper and Hooli. You have configured two webhooks listening for `user.create` events. One updates a separate user database, the other records information in an analytics system. Both the Pied Piper and Hooli tenants have the `user.create` event enabled in their webhook configurations and both webhooks are selected to receive events from both tenants.
+
+In this scenario, each webhook will receive data when a user is created in either tenant, Pied Piper or Hooli.
+
+Transaction settings can be managed at the tenant level. It is possible, for example, to require only the analytics webhook to succeed for the Pied Piper tenant and only the user database sync to succeed for the Hooli tenant.
+
+If you are separating your staging and production environments using tenants, webhooks will not cross those boundaries except for the instance scoped events.
+
 == Retries
 
 If the webhook transaction succeeds, FusionAuth will try to send the payload to any failed webhooks again. For example, if there are three webhooks set up to listen to a `user.update` request, and the transaction level is set to "Any single webhook must succeed" and one webhook succeeds, the two failures will be retried. FusionAuth will retry sending the payload up to three additional times. This retry logic means that webhook endpoints may receive a payload multiple times and should be prepared to handle such a situation.