API docsAgent tools

Integrations and API

Why was a webhook not received?

In short

Why did my Reply webhook not fire?

Reply retries a failed delivery for about two hours before giving up, and switches a subscription off after repeated failures over several days. Check your endpoint responded with a success status within ten seconds, then check the subscription is still enabled and its scope covers the user whose activity you expected.

Quick fix

  1. Check the subscription is still enabled – repeated failures switch it off automatically, and the owner is emailed when that happens.
  2. Check the subscription's scope. A personal webhook only receives the activity of the user who created it; a team webhook receives the whole team's.
  3. Confirm your endpoint answers within ten seconds with a success status. A slow endpoint is treated exactly like a broken one.
  4. Confirm the event you expected is one Reply actually sends, and that the subscription is subscribed to it.
  5. Re-enable the subscription if it was switched off, then trigger the event again.

Didn't work? Contact Reply support; the team can check your account directly.

Symptom

An event you expected (a reply, a bounce, a finished contact) did not reach your endpoint. Either nothing arrived at all, or deliveries stopped at some point and never resumed.

Most likely causes

CauseHow to recognize it
Your endpoint did not answer within ten secondsDeliveries appear in your logs but time out; Reply records the attempt as failed
Your endpoint returned an error statusAnything other than a success status counts as a failure, including redirects you did not expect
The subscription was switched off automaticallyDeliveries stopped entirely at a point in time and never resumed. The owner received an email saying the webhook was disabled
The subscription's scope is narrower than you thinkA personal webhook covers only its creator's activity, so a teammate's replies never reach it
The event was never sent because the payload could not be builtNothing appears anywhere – no attempt, no error. Rare, and invisible to you
The event does not exist, or is not subscribedThe activity happens in Reply but no event of that kind is ever sent
A retry ran after you had already deleted or disabled the subscriptionReply re-checks the subscription before each retry and stops if it is gone

Diagnostic checklist

  1. Start at your own endpoint. Its response decides everything: only a success status within ten seconds counts as delivered. A timeout, a 5xx, or an unexpected redirect all fail.
  2. Check whether the subscription is still enabled. This is the most common reason deliveries stop permanently rather than intermittently.
  3. Compare the scope with what you expected. Personal and team webhooks receive very different traffic on a shared account.
  4. Confirm the event exists. Some activity in the product has no corresponding event, and a few events are only sent on the newer payload format.
  5. Check your payload format version. A subscription on an older format does not receive events that were introduced for the newer one.

Resolution

Your endpoint was too slow or returned an error

Answer immediately with a success status and do the work afterwards, in the background. Ten seconds is the whole budget, including your processing. This single change fixes most delivery problems and prevents the automatic switch-off.

The subscription was switched off

Re-enable it. It will not resume on its own. Fix the endpoint first, or it will be switched off again; the count that triggers it accumulates over days, not minutes.

The scope is wrong

Recreate the subscription with team scope if you need the whole team's activity. Scope is decided when the subscription is created.

The event is only on the newer payload format

A few events are sent only to subscriptions using the newer payload version. Recreate the subscription on that version if you need them.

Verification

Trigger the event again and confirm your endpoint received it and answered with a success status inside the timeout. Then leave it a day and confirm deliveries are still arriving; a subscription that is failing intermittently will switch itself off later, not immediately.

Prevention

  • Acknowledge fast, process later. Treat the ten-second budget as the hard constraint it is.
  • Make your handler idempotent. Retries mean the same event can arrive more than once, and a delivery that timed out on your side may still have been processed.
  • Monitor for the disabled-webhook email. It is the only warning you get before deliveries stop for good.
  • Keep well under the limit on active subscriptions per account, and remove ones you no longer consume.

FAQ

How long does Reply keep retrying?

About two hours, over many attempts: frequent at first, then spacing out. After that the event is dropped.

Will I be told if my webhook is switched off?

Yes. The owner receives an email and an in-app notification. Deliveries do not resume until you re-enable it.

Can the same event arrive twice?

Yes. A delivery that your endpoint processed but did not acknowledge in time is retried. Make your handler idempotent.

Does Reply log successful deliveries?

Failures are recorded. Do not rely on Reply as your delivery log: log receipt at your own endpoint.

Still stuck? Contact Reply support

If these steps didn't solve the problem, the Reply support team can look at your account directly. Open the Reply Help Center and send the team a message.

To get an answer faster, include:

  • the event you expected and roughly when it should have fired
  • the status code and response time your endpoint returned
  • whether the subscription is personal or team scope, and whether it is still enabled
  • your timezone

Don't send passwords, API keys, or access tokens, and do not paste your endpoint's authorization header.

Build with Reply