Alerts and webhooks
Operational alerts and signed outbound events keep teams aware of abuse, usage pressure, and lifecycle changes.
Alerts
Alerts are organization-scoped rules for runtime abuse, risky allows, challenge failures, usage pressure, policy changes, key lifecycle, first production traffic, and webhook delivery health. A recommended alert template is just a rule TxnShield creates for you; it is only active when enabled.
Active alert rules create in-app incidents, queue webhook payloads to one selected endpoint, or both. Webhook delivery is never assumed and is never broadcast to every endpoint.
Usage nearing limit uses a percentage of the organization's current plan limit, such as 80, 90, or 95 percent. Usage exceeded uses the plan limit directly and does not need a generic threshold.
Webhooks
Webhooks forward selected TxnShield events to downstream systems. Payloads are signed with HMAC-SHA256 so receivers can verify authenticity before trusting the data.
To send an alert to a webhook, create an active endpoint and select that exact endpoint on the alert rule. If the endpoint is disabled or deleted, TxnShield removes webhook delivery from affected alert rules and leaves in-app delivery enabled.
Webhook endpoints are a paid feature because they connect TxnShield to production incident and operations pipelines.
Troubleshooting
If an alert does not fire, confirm the rule is enabled, the event matches the rule type, and the per-type config has been reached. Event-based alerts do not use count thresholds.
If a webhook does not receive alert events, confirm webhook delivery is enabled on the alert rule, a specific active endpoint is selected, and queued webhook attempts are being delivered.
If a usage alert seems early or late, check the organization's current plan limit and the percentage configured on the usage nearing alert.
Signature validation
Always validate the txnshield-signature header on your receiver before processing the payload. Treat failed validation as an untrusted request.
Next steps