Notifications

Use Notifications to configure where a message is sent, prepare reusable content, and check the delivery result. Channels and templates belong to an Org. This guide uses a temperature Alert Policy as the calling feature.

The walkthrough creates an Email channel and a temperature-alert template, then connects them to the temperature_a policy from Alert Policies. Prepare your deployment's base URL, an authorized access token and the target Org ID. Replace route placeholders, example addresses and credentials with your own values.

Understand Channels, Templates and Delivery

The resources have different responsibilities:

Resource	What you configure or inspect
Channel	The delivery method and connection settings, such as an SMTP server or webhook URL. A channel can also have default recipients and a default template.
Template	Reusable content with {variableName} placeholders and a list of compatible channel types. A caller can instead supply literal subject/content.
Message	A particular notification request, including its selected channels, recipients and content.
Delivery result	The overall outcome and the results reported for individual channels. A recorded alert event alone does not confirm delivery.

Use channels and templates from the same Org as the policy. A single message can target several channels. For the first verification, use one channel and a known recipient so that the result is easy to trace.

Create a Notification Channel

First check the channel types available in your deployment with List Available Channel Types. Get Channel Type Info returns the configSchema and examples for a selected type:

GET /api/v1/orgs/{orgId}/notifications/channels/registry-info/types/email
Authorization: Bearer YOUR_ACCESS_TOKEN

The public create API documents these four types:

Type	Prepare before creating the channel
email	SMTP host, port, account, password, sender address and the server's TLS/SSL settings. The server must be reachable from WEDA Cloud.
linemessage	A LINE Messaging API channel access token and the recipient identifiers required by your selected send mode.
teams	A Microsoft Teams Workflows webhook URL for the intended destination.
webhook	A reachable HTTP endpoint, its accepted method and its expected payload format.

Use Create Channel for each type. The common request fields are name, channelType, config, and optional description, enabled state, delivery settings, default recipients/template and tags. A channel name has a 100-character maximum and no whitespace; duplicate names return 409 Conflict.

Email

Create the example channel disabled while you prepare its template and policy. The API's default is enabled, so set isEnabled: false explicitly:

POST /api/v1/orgs/{orgId}/notifications/channels
Content-Type: application/json
Authorization: Bearer YOUR_ACCESS_TOKEN

{
  "name": "temperature-a-email",
  "channelType": "email",
  "description": "Email delivery for the Temperature A policy",
  "isEnabled": false,
  "commonSettings": {
    "timeout": 30,
    "retryAttempts": 3,
    "retryDelay": 1000
  },
  "config": {
    "host": "smtp.example.com",
    "port": 465,
    "username": "weda-notifications@example.com",
    "password": "YOUR_SMTP_PASSWORD",
    "senderEmail": "weda-notifications@example.com",
    "senderName": "WEDA Operations",
    "secure": true
  }
}

The host, port and secure value are an example combination. Use the port and TLS/SSL mode required by your SMTP server. Required Email config fields are host, port, username, password and senderEmail; senderName and secure are optional.

After 201 Created, keep the returned channelId. Read it with Get Channel:

GET /api/v1/orgs/{orgId}/notifications/channels/{channelId}
Authorization: Bearer YOUR_ACCESS_TOKEN

Check the result: The saved channel is email, its non-secret config and delivery settings match the request, and isEnabled is false. This confirms the configuration was saved; message delivery is checked later.

This example supplies the recipient in the Alert Policy. If you configure channel-level default recipients, Email target values must be valid email addresses and their type is to or cc.

Note: Keep the original credentials for later changes

Channel responses mask SMTP password and LINE accessToken values as ****. This is a display value, not the original credential. Do not copy the masked config into an update request. Keep the real credentials available when changing connection settings.

LINE

Set channelType to linemessage and replace the Email config with a LINE config:

{
  "accessToken": "YOUR_LINE_CHANNEL_ACCESS_TOKEN",
  "sendMode": "push"
}

• accessToken: Obtain it for your LINE Messaging API channel.
• sendMode: The WEDA public API documents push and multicast.
• Recipients: Use the LINE identifiers appropriate to the chosen mode, rather than an email address or display name.

Prepare the account and recipient access using LINE's Sending messages and Messaging API reference. These links describe the external service; WEDA's channel schema determines the fields to submit here.

Microsoft Teams

Set channelType to teams. Its required config.url is the webhook URL generated by your Teams workflow. Follow Microsoft's Create an Incoming Webhook guidance for a workflow using When a Teams webhook request is received.

Use the generated workflow URL, including its required query parameters. The destination is selected by that workflow. Teams uses the notification content; an Email subject is not used as a Teams subject.

Webhook

Set channelType to webhook and configure the receiving endpoint. For example, the following is the config object for a JSON receiver:

{
  "url": "https://alerts.example.com/weda-notifications",
  "method": "POST",
  "contentType": "applicationJson"
}

Replace the example URL with your receiver. The public operation documents GET, POST, PUT and DELETE; select a method accepted by your endpoint and check the returned type schema before using another value.

contentType value	HTTP Content-Type
applicationJson	application/json
applicationFormUrlEncoded	application/x-www-form-urlencoded
textPlain	text/plain

For a JSON receiver, prepare notification content that renders to valid JSON. The channel config selects the transport format; it does not define your receiver's application payload.

Create and Manage Message Templates

Create a template with Create Template. This example targets only Email:

POST /api/v1/orgs/{orgId}/notifications/templates
Content-Type: application/json
Authorization: Bearer YOUR_ACCESS_TOKEN

{
  "name": "temperature-a-alert",
  "subject": "Temperature alert: {streamName}",
  "content": "The configured alert {alertCondition} has fired for {streamName}. Check WEDA for current readings.",
  "channelTypes": ["email"],
  "tags": ["temperature"]
}

• Required: name, content and channelTypes.
• Limits: Name up to 200 characters, subject up to 500, content up to 50,000.
• Compatibility: Declare the channel types that can use this content. Add a type only when the content is appropriate for that destination.
• Variables: Supply a value for each placeholder used by the template. The walkthrough supplies streamName and alertCondition explicitly.
• Subject: Used by Email. LINE, Teams and Webhook use content.

After 201, keep the returned templateId. Use Get Template to verify it:

GET /api/v1/orgs/{orgId}/notifications/templates/{templateId}
Authorization: Bearer YOUR_ACCESS_TOKEN

Check the result: The subject/content retain the intended placeholders and channelTypes contains email.

To maintain templates:

Task	API and result to check
Find an existing template	List Templates, with name/type/tag filters and pagination.
Change content or supported types	Update Template, then GET and verify the saved content. Providing channelTypes replaces that list, so include the types you intend to keep.
Remove an unused template	Delete Template. First update the policies/channels that reference it. After 204, GET should return 404.

Configure Delivery Settings

The Email request above explicitly sets its delivery settings. Use the same units when configuring another channel:

Setting	Unit	Example	Meaning
timeout	Seconds	30	Time budget for channel delivery.
retryAttempts	Count	3	Configured retries after a failed send; 0 requests no retries. The public request range is 0–10.
retryDelay	Milliseconds	1000	Wait one second between retries.

Note: The two time fields use different units

timeout: 30 means 30 seconds. retryDelay: 1000 means one second. Do not enter 30000 for a 30-second timeout. The walkthrough uses explicit settings rather than relying on omitted-value defaults.

When changing settings through Update Channel, verify the saved commonSettings with GET. Use the channel-type schema and valid server settings for your deployment. Retry settings do not guarantee successful delivery or establish a fixed end-to-end completion time.

Use Notifications with Alert Policies

Use the policy from the preceding guide, its Email channel and the new template in the same Org. Replace the body placeholders below with the IDs returned by your create requests:

PATCH /api/v1/orgs/{orgId}/alert-policies/{alertPolicyId}
Content-Type: application/json
Authorization: Bearer YOUR_ACCESS_TOKEN

{
  "notification": {
    "channelIds": ["{channelId}"],
    "templateId": "{templateId}",
    "recipients": [
      {"name": "Operations", "target": "operations@example.com", "type": "to"}
    ],
    "variables": {
      "streamName": "temperature_a",
      "alertCondition": ">80"
    }
  }
}

Use Update Alert Policy, then Get Alert Policy to verify the complete notification object. This replaces the literal message used in the previous guide with the template method.

Caution: Preserve the complete policy notification configuration

The policy's notification object is replaced as a whole. Include every intended channel and recipient. Use either templateId with variables, or literal subject/content, without mixing the two methods.

The example variables are configuration values that you supplied. They are not automatically refreshed sensor readings or event timestamps. Keep the text consistent with the policy when changing its conditions; use WEDA's readings and event details for the current value and time.

Enable the prepared channel with Enable / Disable Channel:

PUT /api/v1/orgs/{orgId}/notifications/channels/{channelId}/status
Content-Type: application/json
Authorization: Bearer YOUR_ACCESS_TOKEN

{
  "isEnabled": true
}

Check the result: After 200 OK, GET the channel and confirm isEnabled: true. Also confirm the policy is enabled, its intended DataStream remains attached, and new readings are arriving. Alert Policies covers the policy's enable action and trigger/reset behavior.

For a new firing event, the example Email content renders as: The configured alert >80 has fired for temperature_a. Check WEDA for current readings. Verify the event and the notification delivery separately.

View Delivery Results

Find the message with List Message Records. Start with the channel used in the walkthrough:

GET /api/v1/orgs/{orgId}/notifications/messages?channelId={channelId}&skipCount=0&maxResultCount=20
Authorization: Bearer YOUR_ACCESS_TOKEN

Inspect the subject, content and timestamps to identify the intended notification, then use its returned messageId with Get Message Status:

GET /api/v1/orgs/{orgId}/notifications/messages/{messageId}
Authorization: Bearer YOUR_ACCESS_TOKEN

Read these fields together:

Field	What to check
messageId, channelIds	Identify this message and its selected channels. These IDs are separate from alertEventId.
subject, content, templateId, variables	Confirm that the intended template and values were used.
status	Overall message status. The current public API lists pending, sent, failed, partial and success.
results[]	Inspect each channel's channelId, name, status, message and sentAt. An overall result alone is insufficient for several channels.
successCount, failureCount, totalCount	Read the delivery counts alongside the channel results. These are not counts of Alert Events.
createdAt, sentAt	Compare creation and send times. A null send time does not establish successful delivery. The public API uses ISO 8601 date-time fields.

Inspect the per-channel results and delivery counts together with the overall status, then confirm receipt at the destination. Acceptance of a notification request does not confirm delivery.

The list API also accepts status, createdAtStart / createdAtEnd, and sentAtStart / sentAtEnd; combined filters use AND. Supply ISO 8601 UTC timestamps to the WEDA API. If a time-filtered search finds nothing, start with the known channel and widen the time window.

Check the result: The walkthrough message identifies your channel and rendered temperature text; its channel result and destination confirm the intended delivery. A saved channel, enabled policy or firing event is only an earlier checkpoint.

Manage Channels and Troubleshoot

Use List Channels to find saved channels by name, type or isEnabled. For changes, GET the channel, prepare the intended values, call Update Channel, and read it back. When replacing a type-specific config, prepare its complete required connection settings and real credentials; a masked response is not a reusable secret source.

To pause a channel, use the same status PUT with isEnabled: false and verify it with GET. This changes channel availability; it does not disable the Alert Policy or resolve its alert event.

Before Delete Channel, remove or replace its references in the policies that use it. The API permanently deletes the channel. After 204 No Content, GET should return 404. Disabling is the reversible choice when you only need a delivery pause.

Observation	Start here
400 creating a channel	Check name length/whitespace, type-specific required fields, Email recipient format and delivery settings.
409 creating a channel or template	Choose a different name and inspect existing resources.
Channel setup returns 503	Check the returned validation detail and the availability of the selected channel type and external service.
Event exists but no message arrives	Check the policy's complete notification object, channel enabled state, recipient, and message records. Event creation is separate from delivery.
Template rendering or compatibility fails	Check channelTypes, every referenced variable, and the selected message method.
Only one destination receives a multi-channel notification	Inspect each results[] entry and the delivery counts; investigate each failed channel separately.
Channel/template/message GET returns 404	Check the exact returned resource ID and the Org used to access it.
Configuration breaks after an update	Read back the saved fields, check omitted nested settings, and re-enter the real credential instead of ****.
Unexpected status or an unreadable delivery response	Retain the HTTP response and message/channel IDs for WEDA support; do not treat it as successful delivery.

After correcting a configuration, verify it with GET and check a subsequent notification's delivery result. This walkthrough uses Alert Policy notifications; it does not require a separate manual-send or test-send API.