Apply review comments to intro paragraphs

Author: lornajane

specification/callbacks.md

@@ -7,7 +7,8 @@ nav_order: 11
 
 # Providing Callbacks
 
-Callbacks are a feature of OAS that provides a relationship between a given [Operation](https://spec.openapis.org/oas/v3.1.0#operation-object) and a [Path Item](https://spec.openapis.org/oas/v3.1.0#path-item-object) that can be implemented by an API consumer. A callback allows an API provider to describe this relationship at design time, indicating that they can call an API consumer at a given URL based on the definition of both the Callback and dynamic values received during a given Operation. These are described as "out-of-band" by the specification as the expectation is the API provider can call such URLs independently of the Operation in which they are defined.
+Callbacks describe an asynchronous request pattern where the API consumer makes a request to the API provider and includes a URL where the response should be sent. The API provider sends an immediate acknowledgement, then when the result is ready, sends it as a request to the URL the consumer supplied.
+The server can use the contents of the Callback and the dynamic values received during a given Operation to make the followup call back to the client (hence the name "callback") at the URL provided.
 
 <figure style="text-align:center">
   <object type="image/svg+xml" data="{{site.baseurl}}/img/callback-object.svg"></object>

specification/webhooks.md

@@ -7,7 +7,7 @@ nav_order: 12
 
 # Providing Webhooks
 
-Webhooks are a style of communication common in the API economy. Their purpose is to provide bi-directional communications from the API provider to the API consumer to support out-of-band events that do not fit into the pattern of REST APIs or Callbacks. Webhooks fulfill similar purposes to Callbacks in that they support transmitting information about asynchronous or long-running communications. The example of payments APIs discussed in the Callbacks topic also provides an example of the real-world implementations of Webhooks. Many payments API providers implement webhooks to communicate the result of payment operations. API consumers can implement a webhook at a URL of their choosing to receive out-of-band updates on a previously submitted, long-running request. This avoids implementing polling patterns, which many API providers find onerous to support.
+Webhooks provide bi-directional communications from the API provider to the API consumer to support out-of-band events that do not fit into the pattern of REST APIs or Callbacks. Webhooks describe a pattern where an API consumer registers in advance to receive requests at a URL of their choosing. When an event occurs to trigger a webhook, the server sends a request containing the event data to the registered URL, and the consumer acknowledges it. Webhooks fulfill similar purposes to Callbacks in that they support transmitting information about asynchronous or long-running communications, but without the requirement to implement polling patterns which many API providers find onerous to support.
 
 Implementing Webhooks typically involves a registration step, which can be defined using regular Operations and allows API consumers to only consume the events they want to receive. [GitHub](https://docs.github.com/en/webhooks/using-webhooks/creating-webhooks) provides a great example of an API provider who makes extensive use of Webhooks and the means to register for specification events.