The receiver verifies the signature, resolves the called number through the number inventory to an account and (when the number belongs to a rep) that rep, rewrites any media URLs to an authenticated in-app proxy, and stores the message. It always answers 200 with empty TwiML except on a failed signature (403) or a genuine storage failure (500, which asks for a redelivery).
Also called: customer replied · MMS photo · text came back · reply capture
- 1Signature verified against the owning account.
- 2The called number is resolved through org_phone_numbers to an account and optional assigned rep.
- 3An unclaimed number holds the message under a sentinel tenant rather than discarding it.
- 4Each MediaUrl is rewritten from the carrier host to /api/comms/mms/... so the browser can load it.
- 5recordInbound stores it, deduplicated on the provider message id.
The route header records that before it existed, replies simply did not arrive: 'Twilio had nowhere to deliver to, so every reply to a Twilio-sent message was dropped on the floor.' The media rewrite is its own incident (Keith 08-14): storing the carrier URL raw meant 'the thread could not render the photo: it fell back to "Attachment 1", and clicking through sent the builder to a Twilio SIGN-IN page for a picture their own customer had just texted them.' And the unclaimed-number rule is stated as a principle: 'That is our problem, not the sender's, so the message is HELD under the sentinel tenant rather than discarded — dropping it would be the exact failure this route exists to fix.'
- Inbound replies had nowhere to be delivered.
- Carrier media URLs required credentials, so photos were unviewable.
- A number bought outside the provisioning flow would have dropped its messages.
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 →