Let business actions notify other systems
A business action can notify systems outside the application as part of its declared behavior. Wildo turns that notification into queued deliveries for the enabled endpoints in the relevant scope.
The application chooses the actions and channels. Endpoint configuration and delivery handling remain separate, so adding a destination does not require editing the business operation.
Example — Tell a customer’s system when work changes
A task operation emits an organisation webhook notification. The organisation’s enabled endpoints receive queued deliveries of that event; endpoints belonging to another organisation are not selected.
For engineers
This selected notification block comes from Wonder Todos’ Todos resource configuration. It shows user-facing and machine-facing notifications beside each other inside an operation:
userNotifications: [
{ target: CoreUserNotificationTarget.USER_SELF, channel: CoreUserNotificationChannel.FRONT_END_SUCCESS },
{ target: CoreUserNotificationTarget.ORGANIZATION_USERS, channel: CoreUserNotificationChannel.WEBSOCKET },
],
m2mNotifications: [{
channel : CoreM2MNotificationChannel.WEBHOOK_ORGANIZATION, level : M2MNotificationLevel.INFO,
}]
},
Register the resource configuration through the shared module as usual. WEBHOOK_ORGANIZATION resolves the organisation from execution context; WEBHOOK_APPLICATION selects application-level configuration. These are different audiences. A custom channel string is vocabulary, not a sender implementation: the corresponding dispatch path must exist.
Connect declaration to actual delivery
M2MWebhookDispatcherBackendService resolves the scope, checks the feature and enabled webhook configuration, then filters enabled endpoints. For the organisation channel it requires a valid organisation identity instead of falling back to application scope. The operation result is serialized through the resource response serializer before fan-out.
The dispatcher serializes the body once, creates a delivery-log row per enabled endpoint and queues each delivery. The worker owns signing, HTTP attempts and retry classification. That separation keeps the business action from waiting for the receiver’s network response.
| Responsibility | Owner |
|---|---|
| Which action emits an event | Resource operation declaration |
| Which organisation receives it | Execution context and scoped webhook configuration |
| Which URLs receive it | Enabled endpoint entries |
| Retries and delivery status | Delivery worker and log |
| What the receiver does | Customer integration |
Enable and place the webhook administration surface and configure the signing infrastructure and worker queue. An operation declaration alone does not create endpoints. If queue submission fails after a row exists, the row remains pending for an administrator retry; do not interpret operation success as receiver acknowledgement.
Continue with signed customer deliveries for the receiver contract and endpoint testing for the diagnostic path.