One recurring integration question is how an organisation should receive CAP alerts and then relay those alerts to several destinations.
That short requirement contains useful ambiguity. “Receive CAP alerts” might mean polling an Atom or RSS feed that links to CAP XML. It might mean accepting pushed CAP over a webhook. It might mean subscribing to an alerting service, receiving files from a partner, or integrating with an existing operational workflow. “Relay them out” is also broad: an organisation may need to update an internal dashboard, notify operational teams, publish a feed for downstream systems, inform partner organisations, or preserve an auditable copy of the CAP message.
This is exactly the kind of problem multi-channel-relay is intended to make less bespoke.
What multi-channel-relay is
multi-channel-relay is the Alert-Hub.org relay service for Common Alerting Protocol messages. The name is intentionally implementation-shaped: the service relays CAP messages, but the underlying model is not limited to one output format.
The relay’s job is deliberately narrow:
- accept an already-formed structured alert message from an authenticated publisher
- record the publish request durably before downstream work begins
- preserve CAP XML when a context needs a stable public alert URL
- publish derived outputs such as RSS or Atom feeds from the recorded alert state
- push alert summaries to configured webhook endpoints
- render concise alert text for operational notification channels
- apply target-level filters, so not every destination has to receive every alert
- keep delivery attempts, failures, retries, and receipts inspectable
- separate operational ownership by context, so one organisation’s routing configuration does not bleed into another’s
That is a different problem from writing the alert itself. multi-channel-relay is not an alert authoring tool, and it is not an issuing authority. It assumes the source boundary matters: who supplied the CAP, what context accepted it, which targets were selected, and what was actually delivered downstream.
For an organisation operating inside its own boundary, that distinction is important. The organisation may not be the authority that authored the public warning, but it may still need a controlled way to move that warning into the systems that staff, services, and partners actually use.
The practical fan-out pattern
The pattern is simple enough to describe:
- An organisation or partner system receives a CAP alert from a known source.
- The received CAP is checked, preserved, and associated with a local operational context.
- The relay creates or reuses a stable CAP URL for that alert.
- One or more configured targets are considered from the same accepted alert state.
- Each target either passes its filter and is delivered, or is recorded as skipped.
- Operators can inspect what was accepted, what was skipped, what was attempted, what succeeded, and what failed.
The first step still needs careful design. An organisation that says “we want to receive CAP alerts” may need one of several entry points:
- pull from an authoritative CAP feed
- accept a push from another system
- submit CAP through an authenticated machine credential
- preserve an upstream public CAP URL while also storing a local copy
- import a file or message from an existing operational workflow
The current relay implementation is strongest on the authenticated submission and outbound publication side. The next useful work is to make the receiving side clearer for organisations that are not themselves CAP producers, but still need to handle CAP safely.
What the relay can do now
The current implementation already has several pieces that are relevant to organisational CAP fan-out.
It has context-scoped access control. A context is the routing and ownership boundary. That means an organisation, partner group, test environment, or project-specific workflow can have its own topics, targets, storage connections, machine credentials, and membership rules.
It has durable publish intake. A publish request is accepted and stored before asynchronous delivery work happens. Workers then claim jobs through the database, retry failed work, and record delivery state. This matters because emergency alerting integration should not depend on a single browser session or one transient process.
It has CAP Store. When enabled, CAP Store preserves submitted CAP XML to configured storage and records the resulting public URL. If the upstream source already supplied an official public CAP URL, the relay can preserve that as the default while still storing a local Alert Hub copy for durability and audit.
It has feed publication. RSS and Atom targets can publish feed pages and stable alert-object links to filesystem or S3-compatible storage. For organisations that need a simple machine-readable downstream interface, a feed remains a pragmatic integration surface.
It has direct push targets. Webhook targets can post a versioned alert summary JSON payload to an organisation-controlled endpoint. That is useful when an internal dashboard, integration broker, workflow system, or automation service needs to be notified without polling a feed. In the first slice this is deliberately unauthenticated webhook delivery, so it is most appropriate for proof-of-concept work, controlled internal networks, or gateways that can add their own authentication boundary.
It has simple operational notification. Telegram targets can send a fixed, backend-rendered text summary of the alert to a configured chat or channel. The relay does not send the whole CAP XML to Telegram. It renders a concise message from CAP fields such as event, severity, urgency, certainty, area, expiry time, and the CAP URL where one is available. That same rendering path is intended to become reusable for future email, Slack, SMS, or other text-first destinations.
It has target-level filters. The first filter modes are intentionally conservative: ALL and HIGH_PRIORITY. ALL keeps the existing behaviour where a selected target receives every selected alert. HIGH_PRIORITY is derived from CAP fields: an actual public alert or update, with immediate or expected urgency, extreme or severe severity, and observed or likely certainty in at least one info block. That gives an organisation a practical split: preserve and publish all CAP alerts to a durable feed, but only push the most urgent ones to interruption-heavy channels.
It has operator diagnostics. Context alert views show accepted alerts, CAP Store status, projected or actual public URLs, delivery attempts, and target status. That gives an implementation partner or operator something concrete to inspect when an alert did not appear where expected.
Why target filters matter
Internal alert distribution is not just “send the same thing everywhere”.
An organisation might want all accepted CAP alerts stored and exposed through an internal Atom feed, but only a subset pushed into a live operations dashboard. It might want high-priority public alerts sent to an on-call coordination channel, while lower-priority updates remain available for review in normal workflows. It might want an integration webhook for one system and a separate feed for partner systems that are more comfortable with polling.
That is the reason for putting the filter on the target rather than on the alert itself. The same accepted CAP message can be useful to several downstream systems, but each destination has a different tolerance for noise, latency, and interruption.
For the first implementation slice, the filter model is deliberately not a general expression language. It uses named modes so the behaviour is inspectable and safe for the native executable build. Later work may add structured custom filters or an expression mode, but the useful first step is simpler: make “all alerts” and “high-priority alerts” explicit choices, record when a target was skipped by its filter, and keep the fan-out history auditable.
What is not finished yet
This is not yet a complete organisational alert distribution product.
Several pieces need to become more explicit before this is a comfortable pattern for broad operational use:
- clearer receiving modes for CAP alerts that originate outside the organisation
- a better onboarding path for “we have a CAP feed; what do we configure?”
- hardening options for webhook delivery, such as shared-secret signing or bearer-token authentication
- stronger validation and preview of incoming CAP before it is relayed
- clearer target templates for common operational destinations, including dashboards, notification tools, and integration brokers
- richer target filters after the first
ALLandHIGH_PRIORITYpresets - more reusable alert text variants, including very short forms for constrained channels
- guidance for preserving upstream authority, provenance, and local audit records
- practical examples for internal dashboards, public feeds, notification channels, and partner integration
That list is useful because it turns a vague integration request into implementable work. The goal is not to hide the complexity. The goal is to put the complexity in the right places: receiving, validation, preservation, routing, delivery, and audit.
Why CAP is still the right centre
The Common Alerting Protocol is not magic. It does not by itself decide who should be notified, which internal system should update, or which team owns the response.
But CAP is a strong centre for this kind of integration because it gives the alert a shared structured form. A downstream system can inspect identifiers, sender, sent time, status, message type, scope, event, urgency, severity, certainty, area, and references without depending entirely on prose in an email or a PDF attachment.
That structure is valuable even when the downstream action is local. An organisation may need to map a flood warning, severe weather warning, power disruption notice, or public safety message into internal response plans. multi-channel-relay is intended to preserve the structured alert while allowing each organisation to decide how it should be distributed locally.
A careful direction
The important question is not “can we pass on an XML document?”
The more useful question is:
How should an organisation receive a CAP alert from a known source, preserve its provenance, and relay it to the right local systems without losing auditability or inventing a one-off integration for every destination?
multi-channel-relay is the current Alert-Hub.org answer to that question. It is still early, but the shape is becoming clear: context-owned configuration, authenticated publishing, durable CAP preservation, target-based delivery, target-level filters, and visible operational status.
The next work should make that shape easier for organisations to evaluate. In particular, the relay needs a clearer story for the first mile of CAP receipt, not only the last mile of feed, webhook, notification, or object publication.
That gives the next implementation slice a plain test: would this make sense to an organisation that has just said, “we need to receive CAP alerts and relay them to several systems”?