> ## Documentation Index
> Fetch the complete documentation index at: https://docs.squasher.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Inbound alert connectors
> Connect monitoring systems to Squasher with native, authenticated webhooks.
Inbound alert connectors turn alerts from another monitoring system into Squasher
incidents. They preserve the source alert's lifecycle: a firing event opens or
updates an incident, an acknowledged event records an update, and a resolved event closes it.
An alert **source** sends alerts into Squasher. A notification **destination** sends
Squasher incident updates to responders. For example, you can receive a Grafana alert
through a source connector, then route the resulting incident to Slack and PagerDuty.
See [Notifications](/features/alerts) to configure destinations and routes.
## Supported sources
Signed CloudWatch alarm notifications delivered by Amazon SNS.
A small JSON contract for custom systems and scripts.
Alertmanager webhook v4 batches, including resolved alerts.
Grafana webhook contact-point notifications.
Datadog monitor transitions using a managed webhook template.
Events API v2 trigger, acknowledge, and resolve payloads.
## Lifecycle and deduplication
Each provider adapter extracts two separate identifiers:
* The **alert key** correlates lifecycle updates for one source alert. It remains
stable from firing through resolution.
* The **event key** identifies one delivery. Retrying the same event does not create
another incident or repeat the same lifecycle transition during the 90-day
delivery-audit and exact-deduplication window.
Squasher also rejects an older lifecycle event after a newer one has been applied.
For batched providers such as Alertmanager and Grafana, each alert in the request is
normalized and correlated independently.
Batch processing is not atomic across the entire request. A mixed batch returns
`207` only when valid items committed but malformed provider items were rejected. The
response includes counts and safe rejection entries, including one aggregate entry for
items beyond the 1,000-item processing bound. Correct rejected items before resending
them. An all-invalid batch returns `422`. Any persistence failure returns `503`, even
when another item already committed. Retry that complete request unchanged with backoff;
original event identities deduplicate prior commits.
Squasher processes each webhook request synchronously with bounded database work. A
request can include up to 1,000 provider alerts, but it can apply at most 64 new
state-changing alert mutations. If the processing bound or scheduling deadline is
reached, Squasher returns retryable `503` with `Retry-After: 5`. Retry the full request
unchanged; already committed event identities are deduplicated.
Delivery audit and exact event-key deduplication use a fixed 90-day window for every
outcome, including alerts whose incidents remain open. The incident and its timeline
remain after detailed delivery rows expire. After 90 days, a previously retained
provider event identity can be processed again; source timestamps and current lifecycle
state still protect against out-of-order transitions.
Connector-created incidents use the `integration` source type and flow through the same
notification routes as Squasher monitors.
## Connect and verify a source
In Squasher, select the project, open **Settings → Integrations**, choose the source, and create
a connector. You can also use the [Alert Connectors API](/api-reference/alert-connectors).
Copy the generated HTTPS endpoint and authentication value into the monitoring system. Secrets
are shown only in the create or rotate response.
Use **Check connection** to validate Squasher's connector state, then trigger a test or
temporary alert at the source. Verify one incident opens, then send its recovery and verify that
the same incident resolves. The check does not fake an upstream vendor delivery.
Route connector incidents to Slack, webhooks, email, or PagerDuty under **Settings →
Notifications**.
## Security and secret rotation
* Squasher accepts connector traffic only over HTTPS and validates each provider's
authentication before parsing the alert.
* AWS CloudWatch uses the SNS signature and the exact configured topic ARN. Other
source connectors use the generated connector credential in the provider-specific
location described on its setup page.
* Store connector credentials in a secret manager. Squasher stores a one-way hash
for generated webhook credentials and shows only a redacted prefix later.
* Rotating a connector secret keeps the previous secret valid for 24 hours. Rotate
through the API or dashboard, replace the source value during the overlap, then
send a firing and recovery test before the old credential expires.
* Disable a connector before planned maintenance. Delete it when the source should
no longer be able to create or update incidents. Deletion immediately revokes its
credentials and resolves active incidents owned by that connector. Sanitized
delivery audit records remain readable by connector ID for the fixed 90-day
retention window. Project deletion immediately removes the retained audit data.
## Troubleshooting
| Symptom | Check |
| ----------------------------------- | ----------------------------------------------------------------------------------------------- |
| `401` response | Bearer/routing credential, SNS signature, and exact configured topic ARN |
| `404` response | Full generated endpoint; the connector may be disabled, deleted, or unknown |
| `413` response | Provider payload exceeds the 300 KB inbound limit |
| `422` response | JSON/provider schema, required fields, lifecycle transition, timestamp, or an all-invalid batch |
| `207` response | Mixed batch: accepted items are committed; correct the rejected provider items before resending |
| `429` response | Sender burst exceeded the edge limit; retry unchanged with exponential backoff and jitter |
| `503` response | Retry the complete unchanged request; original event identities deduplicate any prior commits |
| Management API returns `403` | API key project scope and the required project read/write permission |
| Incident opens but does not resolve | Recovery notifications are enabled and use the same alert key |
| Duplicate-looking incidents | Source alert key or fingerprint changed between lifecycle events |
| No downstream page or message | Connector incident exists, then check notification routes and delivery history |
Do not replace a stable alert key with a timestamp or retry ID. That causes every
delivery to look like a new alert.