A widened but still strict verification path. The account id present on every provider webhook is used to find the credentials that should have signed it; the signature must then verify against those. This covers texts and calls on per-builder sub-accounts, browser-originated calls, and callbacks that carry no phone numbers at all.
Also called: texts stopped arriving · 11200 error · webhook rejected · recordings never showed up
- 1The platform's own token is tried first, then the token of the account that owns the called number
- 2Failing that, the account id in the request body is matched against stored provider bindings and that account's token is tried
- 3For browser calls the client identity carries the account, so that account's credentials are used
- 4This widens WHICH token may verify a request, never whether a request must be verified at all
Each account has its own carrier sub-account, and only the platform's own was trusted to sign incoming requests — which broke three things silently at once. Every inbound text to a builder's number was rejected and never reached the thread, while the person who sent it saw it send fine; every call recording was refused, so recording was switched on and not one call had a recording; and every browser call failed, with the caller hearing "an application error has occurred". Signature verification now resolves whichever carrier account actually signed the request.
- Inbound traffic on per-account carrier sub-accounts silently rejected
- Callbacks without phone numbers unverifiable
- Browser calls rejected by the platform's own security check
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →