Troubleshooting

Common Issues

Diagnose missing requests, HTTP errors, expired endpoints and history access. Recover saved updates and check capture before retrying a failed delivery.

On this page

My webhook request isn’t appearing

Problem: The sender ran, but the list is empty.

Likely cause: Wrong URL, endpoint state, filters or a disconnected inspector.

Diagnose: Compare the sender target with the copied receiving URL and unchanged token. Read its status, response and timestamp; check expiration and clear search, method and status filters.

Resolve: Reconnect or reload saved history. Correct the sender URL or create a fresh endpoint if expired. Check for a capture before retrying.

I received HTTP 410

Problem: The sender received HTTP 410.

Likely cause: An expired/disabled address, or a saved custom 410 response.

Diagnose: Check response configuration and whether a matching request was captured. Read the endpoint deadline and timezone.

Resolve: If this is expiration, create a new endpoint and update the sender. Expired addresses cannot be revived. Reset an intentional simulation when finished.

My request was rejected with HTTP 413

Problem: The sender received HTTP 413.

Likely cause: The body exceeds the ingress limit, or a custom response simulates 413.

Diagnose: Compare the sender body byte count with current usage limits and check saved response configuration. An ingress size rejection is not captured; an export size error is a separate operation.

Resolve: Reduce the body below the published limit before resending. Narrow filters for export failures. Do not assume a configured 413 means persistence failed.

Read current body limits.

I’m receiving HTTP 429

Problem: Creation or delivery returned HTTP 429.

Likely cause: The daily incoming quota, an independent abuse control, or a configured simulation.

Diagnose: Identify which operation returned 429. Check the error code, Retry-After when present, saved response configuration and captured history.

Resolve: A daily quota rejection resets at midnight UTC; other 429 responses do not necessarily follow that schedule. Pause before retrying and avoid rapid recreation or repeated sends.

Daily incoming quota: Anonymous allows 100 admitted arrivals per UTC day across endpoints in the guest creator-IP scope; Developer allows 2,500 across the account. Both reset at midnight UTC. The ingestion response uses INCOMING_DAILY_LIMIT_REACHED and Retry-After gives seconds until that reset. The rejected request is not captured. See the current limits.

Abuse controls: Independent restrictions can return 429 before capture. The hooks safety limiter uses RATE_LIMITED without Retry-After; the edge rate limiter can also return 429 without that header. Creation restrictions may supply their own Retry-After. Follow the header when present; do not assume a midnight reset.

Configured response: An endpoint owner can deliberately return 429, optionally with a custom Retry-After. The request can still be captured; inspect history and the saved response before deciding whether to resend.

I can’t access my endpoint history

Problem: The workspace cannot load history.

Likely cause: Wrong account, missing guest access or endpoint expiration.

Diagnose: Check the endpoint state and use the owning account or original guest browser/session. The receiving token alone is not management access.

Resolve: Return with valid ownership credentials. If the address expired, create a new endpoint. Lost guest access is not guaranteed recoverable by signing in.

My endpoint has expired

Problem: The endpoint deadline has passed.

Likely cause: Temporary endpoint lifetime ended.

Diagnose: Check the displayed expiry time and timezone. Signing in alone does not extend it.

Resolve: Create a new endpoint and replace the sender URL. For future endpoints, an eligible signed-in owner must extend before expiry.

The inspector isn’t updating in real time

Problem: New deliveries stopped appearing live.

Likely cause: Disconnected browser/backend, filters or delayed history loading.

Diagnose: Read the connection banner and sender response, then clear filters. Hooks may still capture while the application backend is unavailable.

Resolve: Use Reconnect or reload when connectivity returns. Latest saved history recovers captures; this is not a guarantee of a complete historical list.

I can’t find an older request

Problem: An older record is missing from the list.

Likely cause: Loaded-history window, filters, retention, expiration or deletion.

Diagnose: Clear filters. The list initially loads the latest 100 and has no older-page navigation. Check endpoint state and record age.

Resolve: Use Export NDJSON for matching accessible retained history beyond the loaded page. Export cannot restore expired or deleted data; retention is not guaranteed access.

My webhook sender reports an error

Problem: The sender reports an error or timeout.

Likely cause: Configured error response, network failure or service failure.

Diagnose: Read the exact sender status/body and timestamp. Compare the saved response and captured history.

Resolve: Check for successful persistence before resending to avoid duplicates. Restore a successful response if simulating failures; let the sender’s policy govern retries.

Why does my webhook return HTTP 200?

Problem: A webhook returns 200 with no response body.

Likely cause: This is the fresh endpoint default.

Diagnose: Inspect history to confirm capture and review the Response tab.

Resolve: Configure and save a custom response for another outcome. WebhookKit captures input; it does not validate or execute your application handler.

Why was a request captured despite an error response?

Problem: A request exists even though the sender received an error.

Likely cause: Capture and the configured HTTP outcome are separate.

Diagnose: Compare the captured timestamp and response configuration with the sender attempt.

Resolve: Keep the capture for diagnosis. Change the saved response if needed. The sender decides whether to retry; repeated attempts may create duplicates.