# The carrier callback was refused Connect refused the carrier's request because it could not prove the request was genuine, and it refuses before answering rather than after. On the carrier's log the call shows as failed at the application; in the workspace there is nothing at all. The usual cause is not a wrong secret but a verification performed outside the workspace that owns the credentials, which reads them as empty. - **Status:** Available - **Audience:** both - **Channels:** phone - **In the app:** #/phone-advanced, #/calls - **Last verified:** 2026-09-10 - **Canonical:** https://connectbyjbrh.com/docs/troubleshooting/carrier-verification-failed/ ## What it looks like Every call to the number fails the same way, immediately, and the caller hears the carrier's own failure treatment rather than anything from Connect. Because the refusal happens before the call is answered, the workspace has no record of it — which is exactly why the carrier's log is the first thing to read. The tell is consistency. A credential or scope problem refuses 100% of calls; a capacity or worker problem refuses some and answers others. If one call in ten gets through, this is not the page you want. ## What it means Only one part of Connect speaks a provider's dialect: the adapter that knows that carrier's signature, its document format and its webhook shape. Verification happens there, and the credentials it verifies against belong to a workspace. If verification runs before the workspace is entered, the credentials it looks for do not exist from where it is standing — not wrong, empty — and every genuine request is refused. > **Careful** This is the first of the six production telephony defects, and it refused *every* real call before pickup while every configuration screen looked correct. Verification and workspace scope are one decision, not two. ## Causes, most likely first 1. **The request is being verified outside the owning workspace.** The credentials read as empty and nothing can pass. Every handler now runs inside the owning workspace, not only the signature check. 2. **The signing secret has been rotated at the carrier and not in the workspace,** or the reverse. Rotation is the second most common cause and the easiest to confirm. 3. **The public URL does not match the one the carrier signs against.** A signature covers the URL that was called; a proxy, a changed host or a missing public URL produces a mismatch that looks like a bad secret and is not. 4. **The number is attached to a different application** than the one whose credentials the workspace holds. 5. **A replayed request.** Each normalised event is stored once against its signature nonce, so a repeat is absorbed rather than acted on twice. This is correct behaviour, not a fault, and it does not refuse first-time calls. ## What Connect completed - Refused an unproven request. Failing closed is the intended behaviour: an unverified call instruction is the one thing a telephony system must never act on. - Wrote nothing that could later be mistaken for a real call — no partial record, no cost, no contact. - Kept the refusal specific to this path. Mail, messages and the rest of the workspace are unaffected. - Preserved replay protection throughout, so nothing was duplicated while the refusals were happening. ## What Connect did not complete - No call was answered and no greeting was played; callers met the carrier's failure handling, not Connect's. - No call record exists, so the calls are invisible in the workspace and countable only on the carrier's side. - No lead, summary, follow-up or timeline entry was created for any of them. - Nobody was notified per call. A run of refusals shows up as an absence of calls, which is precisely why it can go unnoticed for hours. ## What you can do 1. Compare the carrier's call log with the workspace's calls for the same period. - Result: Completed or failed calls on their side with nothing on yours is the signature of this failure, and the fastest audit available on this path. 2. Place one test call and note whether it fails identically. - Result: Total, consistent failure points at credentials or scope; intermittent failure points somewhere else entirely. 3. Check when it started, and what changed then. - Result: A rotation, a release or a hostname change on the same day is almost always the answer. 4. Report it as "every call refused before pickup", with the carrier-side evidence. - Result: That phrasing distinguishes it from a line that answers and fails later, which has entirely different causes. ## What an administrator can do - Confirm the credentials are stored on the workspace that owns the number, and that verification is running inside that workspace. - Confirm the signing secret matches the carrier's current one after any rotation. - Confirm the public URL matches the address the carrier actually calls, including scheme and host. - Confirm the number is attached to the intended voice application, and only that one. > **Note** Do not respond to this by relaxing verification. A telephony webhook that is acted on without proof can be used to place calls in the business's name. The correct fix is always to make the genuine request verifiable, never to make an unverifiable request acceptable. ## When to escalate Escalate as soon as the pattern is confirmed, because no calls are being answered at all and nothing in the workspace will show it. Bring the carrier-side log lines showing calls that reached the application, the time the first one failed, and any credential rotation or release in the hours before. Do not paste raw provider error text containing call or account identifiers into a shared channel. ## Questions ### Why does the workspace show nothing at all? Because the refusal happens before the call is answered and before a record is created. Creating a record for an unverified request would mean an unverified party could write into the workspace, which is the thing verification exists to prevent. ### Could this be a rate limit rather than a signature problem? A rate limit refuses some requests and lets others through, and shows as an intermittent fault. Verification failure refuses all of them, always, from the first attempt. The consistency is the diagnostic. ### Is a repeated webhook a problem? No. Every normalised provider event is stored once against its signature nonce under a partial unique index, so a carrier that delivers an event several times produces one of everything. ## Related - [Connecting a phone line, end to end](https://connectbyjbrh.com/docs/workflows/first-phone-setup/) - [Nobody can reach the number](https://connectbyjbrh.com/docs/troubleshooting/phone-line-not-ringing/) - [Idempotency for retried telephony webhooks](https://connectbyjbrh.com/research/idempotent-telephony-webhooks/) - [Security and isolation](https://connectbyjbrh.com/docs/security/) - [Troubleshooting](https://connectbyjbrh.com/docs/troubleshooting/) ## What this page is based on - AGENTS.md §9a — the phone system, defect 1 and the adapter boundary - PROJECT-STATE.md — telephony defects found by driving the live endpoint - Connect capability registry (docs-source/facts.py)