Integrations
Firewatch integrations fall into two groups.
Alert sources
Section titled “Alert sources”Alert sources create or update Firewatch alert events. Firewatch accepts its versioned alert-ingestion format directly and accepts AWS SNS or SQS event batches through the generated Lambda adapter. API keys scope each source to an organization, while idempotency and correlation keys prevent repeated provider delivery from creating duplicate response state.
The normalized inbound endpoint does not currently verify a generic HMAC signature in addition to the Firewatch API key. When a monitoring provider signs its webhooks, validate that provider signature and freshness in the adapter before forwarding the normalized event.
Use the alert adapter guide when a monitoring provider needs a small normalization layer before it calls Firewatch.
Notification providers
Section titled “Notification providers”Notification providers reach responders or downstream systems:
- SMTP for incident and account-security email;
- Slack for direct responder alerts and incident context;
- Twilio for verified SMS and optional voice delivery;
- outgoing signed webhooks for customer-owned automation.
Self-hosters bring their own provider credentials. Firewatch Cloud manages provider infrastructure according to the subscribed plan.
Provider secrets belong in deployment secret storage, never in source control or browser-visible configuration.
Outbound customer automation should use signed outbound webhooks. Slack interaction requests use Slack’s timestamped signing contract; that is separate from alert-source authentication and outbound webhook signatures.