Skip to content
Docs

Troubleshooting

Why was my webhook endpoint disabled?

Emailit disables a webhook after 3 days of continuous delivery failures. Find out why deliveries failed, re-enable the endpoint and resend events.

Updated Oct 1, 2026

This article explains why Emailit stops sending events to a webhook, how to find the underlying error and how to recover the events you missed.

Symptoms

  • You received an email from Emailit saying your webhook is failing, and later one saying it was disabled.
  • The webhook shows as disabled in Email APIWebhooks, and new events no longer reach your endpoint.
  • The Requests tab on the webhook page lists requests with the status Failed and many attempts.

Cause

Emailit treats any 2xx response as a success. Everything else counts as a failure, including:

  • 4xx or 5xx status codes, for example from signature checks or crashes.
  • No response within 30 seconds.
  • Redirects. Emailit doesn’t follow 301 or 302, so an http:// URL that redirects to https://, or a missing trailing slash, fails every time.
  • DNS, TLS certificate or connection errors.

Failed requests are retried after 5 minutes, 30 minutes, 2 hours, 5 hours and then every 12 hours, up to 11 attempts. Emailit emails the workspace owner when a request fails for the third time. If the endpoint keeps failing with no successful delivery for 3 days, the webhook is disabled and the owner gets another email.

While a webhook is disabled, new events aren’t queued for it.

Fix

  1. Find the error. Open the webhook and select the Requests tab. Open a failed request to see the Failure reason, the Status code and the response body your endpoint returned.

  2. Fix the endpoint. Common fixes:

    • Use the final URL, with https:// and the exact path, so no redirect happens.
    • Return 200 quickly and do slow work in a background job, so you stay under 30 seconds.
    • Fix signature verification. See Why doesn’t my webhook signature match?.
    • Allow Emailit’s requests through your firewall, WAF or bot protection.
  3. Test it. Choose Send test, pick an event type and confirm the dialog shows a 2xx status.

  4. Re-enable and resend. Choose Retry failed. It re-queues every failed request from the last 7 days and turns the webhook back on. You can also select Enable webhook, or call Retry failed requests.

  5. Backfill events from the disabled period. Events created while the webhook was off weren’t queued. Fetch them with List events, filtering by type and created_at.

To make your handler resilient, make it idempotent with the event_id field, because a retried batch can arrive twice. See Retries and failures.

Still stuck?

Contact support or ask in Discord with the webhook ID (wh_…) and the failure reason from the Requests tab.

Was this page helpful?

Thanks for the feedback.

Thanks, we read every message.