--FusionAuth/fusionauth-issues#1812

Documentation updates for APIs related to webhook changes.

Author: robfusion

site/assets/img/docs/core-concepts/tenant-configuration-webhooks-settings.png

@@ -131,38 +131,18 @@ The password to be used for HTTP Basic Authentication.
 The SSL certificate in PEM format to be used when connecting to the webhook. When provided an in memory keystore will be generated in order to complete the `https` connection to the webhook.
 
 
-=== Applications
-include::docs/v1/tech/events-webhooks/_application-webhooks-warning.adoc[]
-
-image::webhook-settings-applications.png[Webhook Settings - All applications,width=1200,role=shadowed bottom-cropped top-cropped]
-
-image::webhook-settings-applications-selection.png[Webhook Settings - Select Applications,width=1200,role=shadowed bottom-cropped top-cropped]
-
-
-==== Form Fields
-
-[.api]
-All applications::
-When this toggle is enabled, all events will be sent to this webhook, events for a specific application.
-
-Applications::
-When the [field]#All applications# is disabled, this field will be exposed. Select the application for which you would like to receive events.
-+
-Not all events are considered application specific and selecting an application will limit you to only receiving application events. The following events are considered Application events:
-+
-    - `jwt.public-key.update`
-    - `jwt.refresh-token.revoke`
-    - `user.action`
-+
-In most cases you will want to use the [field]#All applications# configuration.
-
 === Tenants
+[NOTE.since]
+====
 Available since 1.37.0
+====
 
 Here's the configuration when a webhook will be sent for all tenants.
+
 image::webhook-settings-tenants.png[Webhook Settings - All applications,width=1200,role=shadowed bottom-cropped top-cropped]
 
 Here's the configuration when a webhook should be sent for certain tenants.
+
 image::webhook-settings-tenants-selection.png[Webhook Settings - Select Applications,width=1200,role=shadowed bottom-cropped top-cropped]
 
 
@@ -187,7 +167,7 @@ These events are configured at the instance level and cannot be limited to a cer
 
 === Headers
 
-image::webhook-settings-headers.png[Webhook Settings - HTTP Headers,width=1200,role=shadowed top-cropped]
+image::webhook-settings-headers.png[Webhook Settings - HTTP Headers,width=1200,role=top-cropped]
 
 ==== Form Fields
 
@@ -197,6 +177,30 @@ The name of the header to add to the HTTP request when sending the event to the
 Value::
 The header value to add to the HTTP request when sending the event to the webhook
 
+=== Applications
+include::docs/v1/tech/events-webhooks/_application-webhooks-warning.adoc[]
+
+image::webhook-settings-applications.png[Webhook Settings - All applications,width=1200,role=shadowed bottom-cropped top-cropped]
+
+image::webhook-settings-applications-selection.png[Webhook Settings - Select Applications,width=1200,role=shadowed bottom-cropped top-cropped]
+
+==== Form Fields
+
+[.api]
+All applications::
+When this toggle is enabled, all events will be sent to this webhook, events for a specific application.
+
+Applications::
+When the [field]#All applications# is disabled, this field will be exposed. Select the application for which you would like to receive events.
++
+Not all events are considered application specific and selecting an application will limit you to only receiving application events. The following events are considered Application events:
++
+- `jwt.public-key.update`
+- `jwt.refresh-token.revoke`
+- `user.action`
++
+In most cases you will want to use the [field]#All applications# configuration.
+
 == Test a Webhook
 
 Once you have a webhook up and running and configured to receive JSON events from FusionAuth you may wish to test it by sending different events. FusionAuth has built in a test capability to allow you to construct any event and send it to your webhook.

site/assets/img/docs/webhook-settings-headers.png

@@ -18,8 +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 Before 1.37.0>>
 ** <<Example Configuration After 1.37.0>>
+** <<Example Configuration Before 1.37.0>>
 * <<Retries>>
 ** <<Retry Examples>>
 * <<Calling FusionAuth APIs In Webhooks>>
@@ -55,27 +55,27 @@ 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 Before 1.37.0
+=== 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. 
+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, but the webhooks receiving an event are not. Any webhook that is configured to receive the `user.create` event will play a role in the transaction. It is not 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 need this level of granularity, run different FusionAuth instances.
-
-If you are separating your staging and production environments using tenants, webhooks will cross those boundaries. While you can filter on the tenant in the webhook itself, if you register both a production webhook and a staging webhook for the same event, the production webhook will receive staging data and the staging webhook will receive production data. In addition, webhook transactions will depend on both. The workaround is to run separate FusionAuth instances.
+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.
 
-Please review this issue for additional information about https://github.com/FusionAuth/fusionauth-issues/issues/1543[future webhook improvements].
+If you are separating your staging and production environments using tenants, webhooks will not cross those boundaries except for the instance scoped events.
 
-=== Example Configuration After 1.37.0
+=== 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 and both webhooks are selected to receive events from both tenants.
+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.
 
 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.
+Transaction settings can be managed at the tenant level, but the webhooks receiving an event are not. Any webhook that is configured to receive the `user.create` event will play a role in the transaction. It is not 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 need this level of granularity, run different FusionAuth instances.
 
-If you are separating your staging and production environments using tenants, webhooks will not cross those boundaries except for the instance scoped events.
+If you are separating your staging and production environments using tenants, webhooks will cross those boundaries. While you can filter on the tenant in the webhook itself, if you register both a production webhook and a staging webhook for the same event, the production webhook will receive staging data and the staging webhook will receive production data. In addition, webhook transactions will depend on both. The workaround is to run separate FusionAuth instances.
+
+Please review this issue for additional information about https://github.com/FusionAuth/fusionauth-issues/issues/1543[future webhook improvements].
 
 == Retries