Troubleshooting

Find the thing you're actually seeing, then work from there. Each entry ends with the exact error string SignalBin returns, in case you're reading logs or scripting against the API.

Nothing shows up in the Webhooks list

The sender is getting an error back. Which one tells you why.

When a capture works, SignalBin answers 202 Accepted and the request appears under Webhooks within a second or two. Everything below is a rejection, and nothing is stored in any of them.

The sender says the payload is too big

The request body is over SignalBin's 20 MiB hard cap. Nothing is stored, not even a truncated copy.

Have the sender reduce the payload, or split it into multiple requests. There's no per-plan override for this limit, and it isn't configurable per workspace. If you're regularly sending payloads near that size, redesign the sender to trim the body rather than treating this as a temporary limit to raise. The cap is checked before credit is, so an oversized request never gets the chance to spend anything.

Technical detail: 413 payload_too_large.

The sender says payment is required, or you're out of credit

Your workspace balance is below what this request costs. SignalBin bills the body, the headers, and 256 bytes of metadata per capture, so a request can be refused while the balance still looks close.

Go to Billing in the sidebar, click Buy traffic, set the Traffic amount, and complete the purchase. Or wait for it to replenish if your plan includes recurring credit.

Technical detail: 402, either insufficient_credit (some credit left, not enough for this request) or credit_exhausted (balance at or below zero).

The sender says the URL doesn't exist

The workspace slug or endpoint slug in the URL doesn't resolve. A disabled or deleted endpoint answers exactly like one that never existed, which is deliberate.

Go to Endpoints and compare the address in the URL column against what your sender is configured with. Check the endpoint isn't showing a Disabled badge next to its name; if it is, open its row menu and choose Enable.

Technical detail: 404 endpoint_not_found.

The sender is rejected as unauthorized

The endpoint has a shared secret and the request didn't carry a matching one. You'll see a value in the Secret column on the Endpoints page for any endpoint that has one.

Send the secret as an X-SignalBin-Secret header or a ?secret= query parameter. If you've lost the value, use Rotate and reveal secret in the row menu to generate a fresh one and update the sender. To stop requiring a secret at all, choose Remove secret from the same menu.

Technical detail: 401 invalid_endpoint_secret.

The sender is rejected as forbidden

The endpoint has a network allowlist and the request's source address isn't in it.

Open the endpoint, go to its Network allowlist tab, and either add the sender's address with Add entry or remove the entries you no longer need by clicking the x on each chip. An empty list means anything can send.

Technical detail: 403 ip_not_allowed.

A multipart upload is rejected

The request declares multipart/form-data, but the body doesn't parse against the boundary in its content type. Fix the boundary the sender writes, or send a content type that matches the body.

Technical detail: 400 invalid_multipart.

INFO

The sender got an unusual response, but the webhook is in the list anyway. A mock-response rule on the endpoint matched the request's method and path, so SignalBin sent that rule's status code, body, and content type in place of the default reply, after whatever delay the rule configures. The capture is stored and billed as normal. Open the endpoint's Mock response tab when the response your sender sees isn't the one you expect.

Captures arrive, but a destination never gets its copy

Work through these in order.

1. Is the destination enabled? Open the endpoint and check the Status column on its Destinations tab. Fan-out only relays to destinations marked Enabled. A Disabled one still shows up in the list, it just stops receiving traffic until you re-enable it from its row menu. This is the most common cause and the first thing to check.

2. Did it actually save? An endpoint holds at most 10 real destinations. Adding an 11th doesn't silently drop it: the app tells you the endpoint already has the maximum, and nothing is created. If you scripted destination creation, check you're handling that response rather than assuming success. (409 destination_limit_reached, with the cap in a limit field. A malformed destination fails earlier with 400 invalid_destination for a bad method, over 20 strip or inject headers, or an unusable header name or value, and 400 destination_target_not_allowed for the address restriction below.)

3. Is the URL actually reachable? When a destination times out, refuses the connection, or returns a 5xx, SignalBin retries twice, roughly half a second and two seconds later, for 3 attempts in total. Each attempt is capped at 10 seconds and the whole fan-out for one captured webhook is capped at 30 seconds across every destination, so consistently slow targets can use up that budget before the retries run. A 4xx response is treated as the destination successfully rejecting the payload and is not retried. If your destination is returning 4xx, the problem is what it received, not delivery itself.

4. Is the destination redirecting? Redirects are never followed. A 3xx is recorded as the delivery's outcome and the payload never reaches the redirect target. Point the destination at the final URL instead.

5. Check its failure count. The Status column shows a badge counting consecutive failed deliveries once there have been any. A climbing count with no successes points at the URL, TLS, or a hang on the receiving end. Note that this tracks reachability rather than acceptance, so a destination answering 4xx to everything still looks healthy. For the outcome of one specific attempt, open the capture under Webhooks and read its Deliveries section.

WARNING

Past 10 destinations, new ones fail rather than replacing or queuing anything. If you need more than 10 targets, consolidate behind a router on your own infrastructure instead.

INFO

Destination URLs can't point at loopback, link-local, or private addresses, or at the 169.254.169.254 cloud metadata address. That's a deliberate guard against server-side request forgery, not a bug. Saving one fails with "That URL isn't allowed - it must be a public http/https address", and a host that only resolves somewhere disallowed later is refused again at connection time. If you're trying to receive webhooks on your own machine while developing, use signalbin listen instead of a real destination pointed at localhost. (400 destination_target_not_allowed.)

Replay doesn't behave like the original delivery

The destination rejects a replayed request that it accepted the first time. Replay resends the stored copy of the capture, not the original bytes, and SignalBin redacts sensitive values on the way into storage. A signature header arrives at the destination as [redacted], so a provider signature check downstream fails on a replay. The automatic fan-out at capture time isn't affected, since it relays the request as the provider sent it. See Headers & Signature Passthrough for the full list of what gets redacted.

A replay delivers an empty body. Retention already dropped the capture's body. If the capture's Body section reads "Body was removed by retention or was empty", there's nothing left to send. Replay a capture before its payload ages out; Webhooks & Replay covers the retention window.

Replay tells you to add a destination first. Replay only sends to the endpoint's enabled destinations, and this endpoint has none. Open the endpoint's Destinations tab, then Add destination or re-enable an existing one, and replay again. (400 no_destinations.)

Replaying against a destination fails immediately. Replay delivers through the same destination configuration as fan-out, including its header strip and inject rules, method override, and the same address restrictions on the URL. If fan-out to that destination is also failing, replay will fail the same way. Fix the destination, not the replay.

A replay you triggered doesn't appear under Deliveries. That section holds the 15 most recent attempts for a capture, counting both automatic fan-out and manual replays, so an endpoint near the 10-destination cap can push older attempts out of view after a couple of replays. If nothing was displaced, check that the delivery request itself succeeded: a failed record of a successful delivery is logged server-side but won't produce a new entry.

A captured webhook is never relayed at all, with no error recorded. Two guards can drop an automatic fan-out silently. SignalBin refuses to relay a request that has already been relayed once, which stops a destination pointed back at a SignalBin ingest URL from looping forever, and it skips fan-out entirely while 64 other captures are already relaying server-wide. Neither guard applies to a manual replay, so if you intentionally chain SignalBin endpoints together, replay still goes through. See Headers & Signature Passthrough for the hop-count header behind the loop guard.

Still stuck?

If none of the above explains what you're seeing, note the request ID (it's on the capture's detail page under Request ID, and Copy ID in the row menu puts it on your clipboard) or the endpoint slug and rough timestamp, then reach out. That's enough for support to look up exactly what SignalBin recorded.