Fix failed deliveries

What to know

• SendingThe delivery is waiting or currently being sent. Approved photos first wait through a 10-second retraction window. If Sending persists, check queue health and pacing rather than assuming arrival: at most three deliveries are in flight per webhook endpoint or Slack connection at a time.
• DeliveredThe destination accepted the delivery. Match the copyable delivery/event ID to X-Snapbar-Event-Id and the idempotency key to Idempotency-Key in receiver logs, then use the submission and endpoint IDs to find the business result. A media_only delivery has no lead email. For a managed destination, ask its owner to match the submission and recorded delivery time before considering any further action.
• RetryingA temporary provider, receiver, or network failure occurred. Snapbar retries on the delivery retry ladder in Partner API errors and limits: nine attempts in all, spread over several hours, after which the row becomes Action needed. Automatic retries resend the original envelope with the destination settings and field mapping captured on the first attempt; a manual replay keeps the envelope but picks up the current settings and mapping.
• Action neededThe failure is permanent until a person fixes its cause. Common causes include expired access, invalid field setup, a receiver rejecting the request with a client error, a receiver hostname that resolves to a private or loopback address, or a permanent redirect. A webhook endpoint that is already Failing gets one attempt per photo, so its rows land here quickly; fix the receiver, then replay. Nine exhausted attempts also end here.
• Needs verificationSnapbar cannot prove whether the receiver completed the original request. It is rare: a send that times out is retried rather than marked uncertain. Replaying without checking can create a duplicate, so the replay asks you to confirm you checked.
• Skipped with reasonOne of three things happened. The lead lacked the required consent or, for a managed destination, an email address; leave those skipped. The webhook endpoint was deleted or auto-disabled before the send, which marks every undelivered row for it skipped; register a new endpoint for future photos instead of replaying. Or a host took back an approval before the delivery went out (the row records APPROVAL_RETRACTED); that row revives on its own when the photo is approved again, and replaying it while the photo is still held only skips it again.
• PausedA destination was paused, or the account integration switch was off, when the delivery was claimed. It resumes automatically when the switch returns. A row paused for a destination or endpoint that no longer exists is closed as Skipped with reason after about an hour.
• API status values.The same rows are available to a key with the operations preset through GET /deliveries. The status table in Partner API reference maps each API value to the label shown here.
• Payload retention.Ninety days after a delivery finishes, Snapbar clears its stored payload and keeps the row, status, and attempt history; a later replay is rebuilt from current data. The full retention and deletion rules are in Partner API reference.
• Snapbar is alerted too.Snapbar is alerted internally when an endpoint turns Failing or Disabled, or permanent failures pile up. The account primary owner is also emailed after automatic disablement; this is not an immediate warning when an endpoint first becomes Failing. Name an event operator to watch Activity and the endpoint status during the event, and verify the owner email address before launch.