HTTP Status Code Reference

Used when upgrading an HTTP connection to WebSocket, such as for real-time webhook streaming or tunnel connections.

Some webhook endpoints return 102 to indicate they have received the payload and are processing it asynchronously. Treat as a successful receipt.

The most common success response for webhook deliveries. Your endpoint processed the payload successfully. Hookbase marks the delivery as successful.

Some webhook endpoints return 201 to indicate the event created a new record in their system. Treated as a successful delivery.

Ideal response for webhook endpoints. Signals the payload was received and queued for async processing. Providers like Stripe and GitHub treat this as success.

A perfectly valid webhook response. Tells the sender "received, nothing to report back." Minimizes bandwidth. Hookbase treats this as success.

The destination URL has permanently moved. Update your destination configuration to the new URL to avoid unnecessary redirects and latency.

The destination is temporarily at a different URL. Most webhook delivery systems will follow the redirect, but the original URL should still be used for future requests.

Unlike 302, this preserves the HTTP method (POST stays POST). Webhook delivery systems should follow this redirect and re-send the payload to the new URL.

Like 301 but preserves the HTTP method. Update your destination URL permanently. The POST request and payload will be forwarded correctly.

Your webhook payload is malformed or missing required fields. Check your transform output, content-type header, and payload structure. This is not retried by default since the same payload will fail again.

The destination requires authentication. Check that your API key, Bearer token, or webhook signing secret in the destination config is correct and not expired.

The destination server recognized your credentials but denied access. Check IP allowlists at the destination, API key permissions, or CORS settings. Retrying will not help without fixing the auth issue.

The destination webhook URL does not exist. Verify the endpoint path in your destination configuration. The endpoint may have been removed or the URL may contain a typo.

The destination does not accept the HTTP method used (usually POST). Check if the endpoint expects a different method, or if a reverse proxy is blocking POST requests.

The destination server did not receive the complete request in time. This is usually a network issue and is safe to retry. Consider if the destination is behind a slow proxy or firewall.

The webhook event conflicts with existing state at the destination (e.g., duplicate event, out-of-order update). Check your deduplication strategy. The destination may have already processed this event.

The destination endpoint has been permanently removed. Unlike 404, this is intentional and permanent. Remove or update this destination in your route configuration.

Your webhook payload exceeds the destination's size limit. Use a transform to trim unnecessary fields, or split large payloads into smaller chunks. Common limits: 256KB-10MB depending on the provider.

The destination does not accept the Content-Type of your payload. Most webhook endpoints expect application/json. Check your destination config and transform output format.

If your webhook endpoint returns this, it has a sense of humor. Not a valid webhook response in production. Check if a mock server or test stub is accidentally deployed.

The payload is valid JSON but semantically incorrect for the destination. Your transform may be producing output that doesn't match the destination's expected schema. Check field names, types, and required fields.

The destination is rate-limiting your deliveries. Check the Retry-After header in the response. Configure rate limits on your route to match the destination's limits. Hookbase will automatically back off and retry.

Your webhook request headers exceed the destination's limits. Review custom headers in your destination config and remove unnecessary ones.

The destination server crashed while processing your webhook. This is a server-side issue at the destination. Safe to retry with backoff. If persistent, contact the destination service's support team.

A proxy or load balancer in front of the destination received a bad response from the actual server. Common during deployments or when the destination is overloaded. Retry with backoff.

The destination is temporarily down for maintenance or overloaded. Check the Retry-After header. Hookbase will automatically retry with exponential backoff. If your circuit breaker triggers, the destination may need attention.

The destination server took too long to respond. The webhook may have been received but processing was slow. Check if the destination does heavy synchronous processing — it should return 202 quickly and process asynchronously.

May indicate a webhook loop — your webhook delivery is triggering another webhook back to itself. Check your routing rules for circular references.

The delivery is hitting a captive portal or network login page instead of the actual destination. This usually means the destination is behind a corporate network that requires VPN or proxy authentication.