Forward CAP alerts to external destinations

Plan destinations and routing

• Create multiple destinations when different systems, locations, or alert classes require different delivery policies.
• Filter each destination by activation, update, or cancellation action; manual or NWS origin; CAP severity; and tenant-owned locations.
• Leave a filter empty only when that destination is intended to accept every value in that tenant.
• Filters decide when a destination joins an alert. After an activation is planned, updates and the final cancellation continue to that active destination even if its filters change, preventing stale signage.
• A destination that first matches an update receives a complete current Alert snapshot. A destination that never joined the alert does not receive an orphan Update or Cancel.
• Do not disable a destination or replace its provider or URL during an alert lifecycle. DMTG CAP blocks those changes until no delivery is pending, every participating alert has ended, and its cancellation or all-clear was delivered. You can still rotate credentials at the same provider and URL to repair a failing delivery.
• Run a non-emergency connectivity test before enabling a destination for live alerts.

Use the generic CAP webhook

1. Enter the receiver’s final public HTTPS URL on port 443. Redirects and private-network targets are rejected.
2. Exchange a unique signing secret of at least 32 characters through an approved secret channel. Add a bearer token only when the receiver requires one.
3. Configure the receiver to accept CAP 1.2 XML and verify the payload digest, delivery identifier, idempotency key, timestamp, nonce, key identifier, and HMAC-SHA256 signature.
4. Rotate receiver credentials deliberately and repeat the connectivity test. Provider or endpoint replacement is available only after every prior alert lifecycle is resolved; queued dispatches are never rerouted to a replacement connection.

Connect Rise Vision

Rise Vision provisions a company-specific Web Service URL. Paste that exact URL into the Rise Vision destination. If you enabled an Authentication Name and Authentication Password in Rise Vision, enter that same pair in DMTG CAP; otherwise leave both fields blank. The URL and optional credentials grant delivery access: treat them as sensitive secrets, keep them out of email, tickets, screenshots, and shared documents, and replace them if exposed. DMTG CAP encrypts them at rest and shows only safe connection status after saving.

The Rise Vision provider profile sends CAP 1.2 XML. Rise Vision asks providers to use fewer than 40 title characters and fewer than 100 description characters, so DMTG CAP normalizes whitespace and caps those fields at 39 and 99 characters. The delivery record notes source lengths and whether a lossy transformation occurred, so write the essential instruction first.

Review delivery, retries, and dead letters

Activation, update, and cancellation deliveries are idempotent per alert version and destination. CAP updates and cancellations include the original message plus the complete chain of prior DMTG-generated updates planned for that destination. Each attempt records request integrity, timing, HTTP status or provider receipt, and a safe error code without exposing destination secrets.

• Durable lifecycle events are reconciled every minute. If planning failed before a dispatch record could be created, DMTG CAP safely recreates only the missing tenant-scoped work without producing orphan updates or cancellations.
• Transient failures receive bounded backoff for up to six automatic attempts.
• Permanent failures and exhausted retries become dead letters; an authorized administrator may request a new bounded retry cycle after fixing the destination.
• A failed external destination does not stop native Windows, macOS, realtime, or polling delivery.
• Future mobile, ChromeOS, signage, or mass-notification adapters must use reviewed provider profiles without weakening tenant isolation.