Per-account API key and TwiML app resources, created on demand the first time a builder places a call and then stored on their provider binding. Everything is idempotent: stored values are reused, and the carrier is re-checked before anything is created.
Also called: error 13214 · valid callerId must be provided · call from the browser · voice token
- 1A rep clicks call in the browser.
- 2The account that owns their number is resolved.
- 3An API key and TwiML app for that account are reused, or created on demand and stored.
- 4The TwiML app is registered against a validated public https www URL.
- 5An access token minted on that account can present the account's own numbers as caller ID.
The header names the error and the misdiagnosis (L2B-KR8Q4D): 'We minted every voice token on the PLATFORM account while each builder's number lives on their own subaccount, so every outbound call came back 13214 — valid callerId must be provided for TwimlClient and SIP calls. The webhook was healthy the whole time; Twilio simply refused to let the parent account speak as a number it does not own. The fix is not to loosen the caller ID — it is to mint the token on the account that actually holds the line.' Creating on demand rather than by migration is also reasoned: a fan-out migration 'would half-fail the moment one subaccount was mid-provisioning and leave no record of which ones took.'
- Browser calls failed because the token was minted on an account that did not own the number.
- A bulk migration of per-account resources would have half-failed silently.
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 →