Inspect webhook history and replay deliveries
Recover from consumer outages without manufacturing new social events.
List webhook delivery history to inspect status, attempts, response codes, and timestamps. After fixing your consumer, request manual replay of the retained delivery and let your event-ID deduplication decide whether downstream work is still required.
What this means in practice
List webhook delivery history to inspect status, attempts, response codes, and timestamps. After fixing your consumer, request manual replay of the retained delivery and let your event-ID deduplication decide whether downstream work is still required.
Use the documented brand and account boundaries consistently across the scheduler, REST API, SDK, MCP tools, SSE consumers, and webhooks. That makes the same social operation explainable to an operator and reproducible by an integration.
Implementation checklist
Identify the subscription and time window affected by the outage.
Fix signature, timeout, routing, or downstream processing problems before replay.
Replay the original retained delivery rather than changing its event identity.
Confirm your consumer handles duplicate delivery safely.
Monitor the backlog until success and dead-letter counts return to normal.
Example request
This example uses a server-side API key and an explicit brand selection. Replace placeholder values and keep credentials out of browser bundles, client logs, and source control.
curl --request POST \
--url 'https://postapi.app9.co/v1/webhook-deliveries/DELIVERY_ID/replay' \
--header 'Authorization: Bearer APP9_POST_API_KEY' \
--header 'X-App9-Post-Brand: BRAND_ID' \
--header 'Content-Type: application/json' \
--data '{}'Operational details
Replay is an operational recovery tool, not a method to republish a social post.
A 2xx response confirms receipt, not necessarily completion of your downstream business logic.
Delivery history is scoped to authorized brand administrators.
Common mistakes to avoid
- Do not replay a large window before testing one representative failure.
- Do not create a new event ID to work around broken deduplication.
- Do not expose response bodies that contain your consumer's secrets or private stack traces.