Webhook reliability

What does HTTP 200 actually prove for a webhook?

See what a successful webhook response establishes at the protocol layer—and what it cannot prove about business processing.

Updated Aug 27, 2026

An HTTP 200 is an HTTP response, not a universal webhook contract. Webhook providers commonly use a qualifying 2xx response as their protocol-level success signal, but the exact acknowledgement, retry, and acceptance behaviour is defined by each provider. A 200 does not, by itself, prove that every operation triggered by the request completed successfully.

What a qualifying 2xx can establish

At the protocol boundary, a provider may treat a qualifying 2xx response as evidence that its delivery reached an accepting endpoint. What that response means for retries or downstream processing is provider-specific.

What it cannot prove

  • that a database commit completed after the response;
  • that an asynchronous job ran to completion;
  • that an email was sent;
  • that an account was provisioned;
  • that a downstream API call succeeded; or
  • that all related business state is consistent.

This is why acknowledge-fast designs need durable capture, job visibility, and reconciliation. Returning 200 before slow work is often correct, but only when the accepted Event and its responsibility have been recorded somewhere reliable.

Delivered is not business completion

Webhook Handoff uses “Delivered” to mean that it received a qualifying successful HTTP response from the configured Destination. That is useful transport evidence. It is not a claim that the Destination committed a business transaction or completed every side effect.

The distinction also applies to provider ingress. A provider can stop retrying after your endpoint responds successfully while your own asynchronous processing is still pending or failed. Durable identity and operational recovery close that gap.

Use the response as one signal

Combine protocol responses with durable Event records, attempt history, queue state, and application-level outcomes. When the response is ambiguous, prefer a recorded identity and a deliberate reconciliation decision over an assumption that the operation either definitely happened or definitely did not.