Audit Webhook Delivery - SEC API for AI

Use delivery history to answer a specific operational question: did our endpoint receive a monitor.match, what did it return, and should a human replay it after fixing the receiver?

Read attempts with an API key

curl --fail-with-body -H "x-api-key: $SECAPI_API_KEY" \
  "https://api.secapi.ai/v1/webhook_endpoints/wh_123/deliveries?limit=20" \
  | jq '{data, hasMore, nextCursor, requestId, traceparent}'

Each delivery attempt is an audit record. Capture its id, event type, status, timestamps, latency, request id, and replayedFromDeliveryId when present. Join it to the event id and filing identifiers your receiver stored; an HTTP status alone does not prove that downstream processing succeeded.

Triage one failed delivery

Confirm the receiver verified the raw-body signature and accepted the event id only once.
Compare the receiver log timestamp with the delivery attempt and request id.
Fix the receiver, destination, or secret handling before asking for a replay.
Verify the new attempt and preserve its replay lineage with the original record.

Replay, endpoint changes, tests, and secret rotation belong in the signed-in dashboard because they are organization control-plane actions. Do not attempt them with an API key or delegate them to an agent.

Common failure modes

401 from the receiver: signature verification uses parsed JSON or the wrong signing secret.
Repeated 5xx: accept and queue quickly; move slow filing retrieval out of the request handler.
Duplicate work: the receiver did not persist the event/delivery id before processing.
Missing record: page through nextCursor and check the endpoint subscription before assuming a delivery was sent.

Read Webhook and stream workflows for the receiver contract and Webhook delivery and event types for event-specific limits.

​Read attempts with an API key

​Triage one failed delivery

​Common failure modes

Read attempts with an API key

Triage one failed delivery

Common failure modes