links

src/pages/app-development/starter-kit/events.md

@@ -115,6 +115,49 @@ webhook:
     final: true
 ```
 
+## `consumer` action
+
+The main purpose of this action is to route events to the [`event handler` action](#event-handler-action). Normally, this routing is determined by the name of the event received.
+
+The `consumer` action is subscribed to a set of events. In many cases, all the events originate from the same entity, such as the `product` entity. However, there are examples where a consumer receives events from multiple entities belonging to the same "domain", such as `order` and `shipment`. When the event provider receives an event, this runtime action will be automatically activated.
+
+The response returned by a `consumer` action is expected to be consistent with the response received from the activation of the subsequent `event handler` action. For example, if the `event handler` action returns an `HTTP/400` status, the consumer action is expected to respond with the same status. This ensures that the event processing is appropriately retried based on the event handler action response.
+
+When it receives an event that it does not know how to route, it is expected to return HTTP/400 status. This will prevent the event handling from being retried.
+
+By default, `consumer` actions have the following response:
+
+<CodeBlock slots="heading, code" repeat="2" languages="JSON, JSON" />
+
+### Success
+
+```js
+// ./actions/responses.js#successResponse
+return {
+  statusCode: 200,
+  body: {
+    type: 'EVENT TYPE',
+    response: {
+      // Response returned by the event handler action
+    }
+  }
+}
+```
+
+### Failure
+
+```js
+// ./actions/responses.js#errorResponse
+return {
+  error: {
+    statusCode: 400, // 404, 500, etc,
+    body : {
+      error: 'YOUR ERROR MESSAGE'
+    }
+  }
+}
+```
+
 ## `event handler` action
 
 The main purpose of this action is to manage an event that notifies you about a change in one of the integrated systems. Typically, its business logic includes an API call to propagate the changes to the other system being integrated.
@@ -155,9 +198,9 @@ return {
 
 ## event ingestion action
 
-The main purpose of this runtime action is to provide an alternative method to deliver events to the integration, if the 3rd-party, back-office application cannot fulfill the [Events Publishing API's](https://developer.adobe.com/events/docs/guides/api/eventsingress_api/) requirements.
+The main purpose of this runtime action is to provide an alternative method to deliver events to the integration, if the 3rd-party, backoffice application cannot fulfill the [Events Publishing API's](https://developer.adobe.com/events/docs/guides/api/eventsingress_api/) requirements.
 
-For more information, see [Ingestion webhooks](./ingestion-webhook.md).
+For more information, see [Ingestion webhooks](#ingestion-webhook).
 
 To get the URL of the webhook, run the following command:
 

src/pages/app-development/starter-kit/receive-data.md

@@ -1,6 +1,6 @@
 ---
 title: Receive data from external sources
-description: Something
+description: Learn about how to receive data from the external backoffice application.
 keywords:
  - Extensibility
  - App Builder
@@ -29,7 +29,7 @@ import integration from '/src/_includes/integration.md'
 
 # Receive data from external sources
 
-This runtime action is responsible for notifying Adobe Commerce when an `<object>` is created, updated, or deleted in the external back-office application.
+This runtime action is responsible for notifying Adobe Commerce when an `<object>` is created, updated, or deleted in the external backoffice application.
 
 <integration />
 
@@ -99,7 +99,7 @@ The incoming data is validated against a JSON schema defined in the `schema.json
 
 ## Payload transformation
 
-If necessary, make any transformation changes necessary for the external back-office application's formatting in the `transformData` function in the `transformer.js` file.
+If necessary, make any transformation changes necessary for the external backoffice application's formatting in the `transformData` function in the `transformer.js` file.
 
 ## Interact with the Adobe Commerce API
 

src/pages/app-development/starter-kit/send-data.md

@@ -1,6 +1,6 @@
 ---
 title: Send Commerce data
-description: Learn about the runtime action responsible for notifying the external back-office application when data is modified in Adobe Commerce.
+description: Learn about the runtime action responsible for notifying the external backoffice application when data is modified in Adobe Commerce.
 keywords:
  - Extensibility
  - App Builder
@@ -17,7 +17,7 @@ import integration from '/src/_includes/integration.md'
 
 # Send Commerce data
 
-This runtime action is responsible for notifying the external back-office application when an `<object>` is created, updated, or deleted in Adobe Commerce.
+This runtime action is responsible for notifying the external backoffice application when an `<object>` is created, updated, or deleted in Adobe Commerce.
 
 <integration />
 
@@ -86,9 +86,9 @@ The `params` also specify the `event_code` and `event_id`.
 
 ## Payload transformation
 
-If necessary, make any transformation changes necessary for the external back-office application's formatting in the `transformData` function in the `transformer.js` file.
+If necessary, make any transformation changes necessary for the external backoffice application's formatting in the `transformData` function in the `transformer.js` file.
 
-## Connect to the back-office application
+## Connect to the backoffice application
 
 Define the connection information in the `sendData` function in the `sender.js` file.  Include all the authentication and connection information in the `sender.js` file or an extracted file outside `index.js`.
 

src/pages/app-development/starter-kit/structure.md

@@ -21,7 +21,7 @@ The Adobe Commerce Extensibility Starter Kit provides boilerplate code to synchr
 - Shipment
 - Stock
 
-By default, object synchronization is bi-directional. Changes in Commerce are propagated to the external back-office application and vice versa.
+By default, object synchronization is bi-directional. Changes in Commerce are propagated to the external backoffice application and vice versa.
 
 The source code follows the [file structure](https://developer.adobe.com/app-builder/docs/guides/extensions/extension_migration_guide/#old-file-structure) of a typical App Builder application. Most importantly, the `actions` directory contains the source code for all the serverless actions.
 

src/pages/app-development/starter-kit/webhooks.md

@@ -25,7 +25,7 @@ The following sections demonstrate all the real-time integrations that Adobe Com
 
 The contents of the `./actions/webhook` directory expose a webhook that can be invoked synchronously from Commerce to affect the behavior of a particular business flow.
 
-The `./actions/webhook/check-stock` folder provides a [reference implementation](./webhooks-example.md) of a synchronous webhook action.
+The `./actions/webhook/check-stock` folder provides a [reference implementation](#webhooks-example) of a synchronous webhook action.
 
 To get the URL of the webhook, run the following command: