Event streams

This page is for administrators. An event stream collects every change of chosen tags and posts them to another system as JSON batches. Because it makes the gateway call out, only an administrator can set one up.

What it does

1. Every value the tag runtime accepts is matched against each enabled stream's tag paths.
2. A matching change is added to that stream's current batch.
3. The batch is sent when it reaches Or once changes, or when its oldest change is Send after seconds old, whichever comes first.
4. The gateway posts the batch to the Webhook address and records the result in Recent batches.
5. A batch the receiver refused is kept and sent again every 10 seconds, before anything newer.

Taking a value only queues it: nothing here can slow the tag runtime.

The Event streams page

Open Automation, then Event streams. The page lists streams with Status, Name, Tags (how many paths) and Batches, and has two row actions: Send a test batch and Delete. Below the list, Recent batches shows the last deliveries with When, Result, Stream, Changes and Detail.

Creating a stream

1. Click the button to add a stream; a panel opens beside the list.
2. Under Stream, give it a Name (up to 80 characters) and leave Sending on. While it is off, nothing is collected or sent.
3. Under Destination, enter the Webhook address: a full http:// or https:// URL, up to 500 characters.
4. Under Batches, set Send after (1 to 300 seconds, default 5) and Or once (1 to 1000 changes, default 100).
5. Under Tags, enter the Tag paths, one per line: an exact path such as Line1.Motor1.Speed, or a folder with .* at the end such as Line1.* to include everything beneath it. Between 1 and 50 paths, each up to 300 characters.
6. Save. The stream is picked up within 5 seconds.

A gateway can hold at most 20 streams.

Matching is exact and case-sensitive. Line1.* matches every path that starts with Line1.; it does not match the tag Line1 itself.

Testing

Send a test batch posts one made-up change (Test.Tag, value 1, quality Good) to the webhook with "test": true and records the result. Use it to check the address and the receiver before real changes flow.

Changing a stream

Editing a stream's name, limits or address keeps the batch it is holding and anything waiting to be resent. Changing its tag paths starts it afresh and drops what it was holding.

Payload

Each batch is one POST with Content-Type: application/json and User-Agent: Scadex-Gateway:

{
  "event": "stream.batch",
  "test": false,
  "stream": "Line 1 to MES",
  "sentAt": "2026-11-08T12:00:05.123Z",
  "events": [
    { "tagPath": "Line1.Motor1.Speed", "value": 1480.5, "quality": "Good", "timestamp": "2026-11-08T12:00:00.871Z" },
    { "tagPath": "Line1.Motor1.Run", "value": true, "quality": "Good", "timestamp": "2026-11-08T12:00:01.002Z" }
  ]
}

• value is the tag's value as JSON. A structured (JSON) value is embedded as an object, bytes are base64 text, and a number that is not finite is null.
• quality is the quality code's name, such as Good, Uncertain or Bad.
• timestamp is the value's own timestamp; sentAt is when the batch left the gateway.
• Events are in the order the gateway accepted them.

Any 2xx answer counts as delivered. Anything else, no answer within 10 seconds, or a connection error, counts as failed.

Delivery log and retries

• Recent batches shows the last 200 deliveries across all streams, newest first, each with sent, failed or resent and a detail of up to 300 characters (HTTP 200, The receiver answered HTTP 503., The receiver didn't answer within 10 seconds.). The log is in memory and empties when the gateway restarts.
• A failed batch is stored and retried every 10 seconds. Stored batches go out oldest first, and newer batches wait behind them so the receiver sees changes in order. A retry that succeeds is logged as resent.
• Each stream keeps at most 50 stored batches; past that the oldest are dropped, so memory stays bounded.
• Stored batches live in memory only: they are lost when the gateway restarts or when the stream's tag paths change.
• Incoming changes wait in a queue of 20,000 across all streams; under a burst larger than that, the oldest queued changes are dropped.

Limits

• Webhook only; no MQTT, Kafka or database destination.
• No authentication header or signing on the request. Put a secret in the URL or restrict the receiver by network if you need one.
• No filtering by value or quality, no transformation of the payload.
• 20 streams, 50 paths each, 1000 changes per batch, 300 seconds of buffering.

API

All routes need the admin role. The full reference is in Admin API.

Route	Purpose
GET /api/v1/admin/event-streams	List streams
POST /api/v1/admin/event-streams	Create {name, enabled?, tagPaths, bufferSeconds?, maxBatch?, webhookUrl}
PUT /api/v1/admin/event-streams/{id}	Replace the same fields
DELETE /api/v1/admin/event-streams/{id}	Delete
POST /api/v1/admin/event-streams/{id}/test	Send a test batch: {status, detail}
GET /api/v1/admin/event-streams/deliveries?limit=	Recent deliveries, newest first, up to 200