Delivery states
The queued worker handles up to 100 eligible pending deliveries per run. Retry delays describe eligibility, not exact arrival time. The direct-trigger path has its own inline attempts, so do not assume every
failed record is terminal or follows the same timetable.
Diagnose in order
- Confirm the subscription is active and the event is selected.
- Confirm the public receiver URL and TLS certificate work.
- Check the logged response status: authentication, signature, timeout and receiver validation failures have different remedies.
- Verify HMAC against the raw body; do not reserialize before verification.
- Ensure your receiver returns
2xxpromptly after durable acceptance. - Confirm downstream processing separately from transport acceptance.
Replay carefully
Use the app’s supported replay control for owned deliveries when available. A replay resends the stored payload and records a new delivery attempt; it does not undo the original business effect. It is not a documented/rest-api resource or MCP tool.
Before replay, fix the receiver and verify duplicate handling. Replaying an event can repeat a CRM write, start an automation or send a message on your receiver. Require approval and avoid bulk replay until a controlled test succeeds.