< woml />
View on GitHub

<provider>

<provider kind="notification"> is the reusable root for a project-specific notification transport.

Why use it

Use it when approvals or lifecycle messages must travel through a provider WOML does not include, while keeping decision authority, retries, and settlement in the Rust runtime.

Common use cases

  • Send approval actions through an internal messaging API.
  • Integrate a project-specific incident system.
  • Standardize one custom notification transport across workflows.

Syntax

WOML
<woml>
  <props>
    <prop name="api-token" required="true" secret="true" />
    <prop name="destination" required="true" />
  </props>
  <provider kind="notification">
    <script>
      return services.http.request({
        url: "https://messaging.example.com/messages",
        method: "POST",
        headers: { authorization: `Bearer ${props.apiToken}` },
        json: {
          destination: props.destination,
          text: notification.message,
          actions: notification.actions
        }
      }, { name: "deliver-notification" });
    </script>
  </provider>
</woml>

Rules and behavior

  • Only kind="notification" exists in v1.
  • The provider script receives props, notification, services, and Fetch.
  • The provider transports bounded notification data but does not own the approval decision.
  • Imported custom provider tags are used directly inside <notify>.
  • Custom provider triggers and child-generating custom tags are not supported.