An inbound webhook was rejected
A refused callback failed one of four checks: it could not be shown to come from the provider, it was too old, it named something Connect does not serve, or it was a repeat of a delivery already handled. Only the first three are faults. The fourth is the retry mechanism working, and it is acknowledged rather than acted on twice.
What the symptom looks like#
The provider's own console shows deliveries failing or retrying. Inside Connect the corresponding events simply do not appear: no call record, no message, no delivery update. Nothing errors on any screen, because nothing arrived to error about. The gap is visible only by comparing the two sides.
A second, quieter shape of the same problem is one-sided: events stopped at some point rather than never starting. That version usually has a date on it, and the date is the most useful fact in the investigation.
What it means#
A callback arrives with no session, so it has to prove itself before anything is written. Verifying an inbound webhook covers the four checks in full. A refusal means one of them was not satisfied, and the delivery was discarded whole rather than partly processed.
Refusing whole is what keeps this failure recoverable. There is no half-written call, no message with a missing sender, no follow-up attached to nothing — so once the cause is fixed, a provider retry lands cleanly and there is nothing to tidy first.
The causes, in order of likelihood#
| Cause | Typical origin | Tell | Fix |
|---|---|---|---|
| Origin cannot be proved | The signing value was changed at the provider and not in Connect, or the reverse | Every delivery fails, starting at a date somebody can name | Set the value again on both sides, in that order |
| The delivery is stale | Clock drift, or a queue that held deliveries for a long time | Intermittent failures that correlate with delay rather than with content | Correct the clock; a provider backlog clears itself |
| The route is unknown | A callback aimed at something this workspace does not serve | Only some kinds of event fail; others arrive normally | Point the provider at what is actually configured |
| A repeat of a handled delivery | The provider retrying after a lost acknowledgement | The event is present in Connect exactly once despite several attempts | Nothing. This is the mechanism working |
What Connect completed, and what it did not#
Completed: the refusal, and the counting of it. The delivery was rejected before its content was interpreted, nothing was written, and the refusal raises an operational signal rather than vanishing. No detail about why is returned to the sender, because a refusal that explains itself helps the next attempt.
Not complete: the event itself. Nothing about it exists in the workspace — no partial record, no queued retry of Connect's own. Recovery depends on the provider retrying, which providers do for a period and then stop. That window is why a run of refusals is worth treating as urgent rather than as noise.
What you can do#
Find the date the deliveries started failing, from the provider's side.
Result A hard start date points at a configuration change. A gradual or intermittent pattern points at time or at a subset of event kinds.
Check whether every event kind fails or only some.
Result All of them points at origin or clock. Some of them points at what the callback names.
Set the signing value again on both sides rather than comparing them.
Result Stored values are sealed and cannot be read back for comparison, so replacing is faster than proving. See Rotating a provider credential, end to end.
Trigger one event you can control, and watch both sides.
Result A single controlled delivery answers in seconds what an afternoon of reading logs answers less certainly.
What an administrator can do, and when to escalate#
- Confirm the callback address configured at the provider is the one this workspace is meant to use, unchanged and complete.
- Check the sending system's clock if failures cluster around delay rather than around content.
- Escalate while the provider is still retrying, not after. Once the retry window closes, the events are gone and no configuration change brings them back.
- Escalate immediately if deliveries are accepted and the events still do not appear — that is a different fault from this one, and worth separating early.
Questions#
Does a rejected delivery mean somebody was attacking the endpoint?
Almost never. The ordinary cause is a mismatch after a change on one side, or a clock. The check exists for the hostile case, but the traffic it actually refuses day to day is misconfigured rather than malicious.
Can Connect ask the provider to resend?
Providers control their own retry behaviour, and some offer a manual redelivery in their console. Connect does not reach back into a provider to demand an event again — which is exactly why fixing the cause inside the retry window matters.
Why does a duplicate delivery not create a duplicate record?
Because each delivery carries an identifier that is recorded once. A second arrival of a recorded identifier is acknowledged without repeating the work, so a retried call event never rings anybody twice.