Two routes — /api/comms/recording/<sid> and /api/comms/mms/<messageSid>/<mediaSid> — that fetch provider media using server-side credentials and stream it to the browser. Both check that the caller is an approved member of an org that actually received that media, so another tenant's id resolves to nothing.
Also called: attachment 1 · can't open the photo · twilio sign in page · broken voicemail link
- 1Ids are format-validated before any lookup
- 2The lookup is scoped by the caller's org, so a foreign sid finds no row rather than returning audio or a photo
- 3The recording route matches both voicemail (vm-) and answered-call (rec-) threading ids
- 4Media never leaves the platform's own origin
Photos a customer texted were stored as raw carrier links, so the thread could not display them — they showed as "Attachment 1", and clicking through took the builder to a carrier sign-in page to see a picture their own customer had just sent them. Call recordings had a matching version of the same problem, where a perfectly valid recording came back as not existing. Recordings and texted photos now stream through the platform with credentials applied on the server, scoped to the account that received them, and play in place.
- Provider media unreachable from the browser
- Customers' photos leading to a third-party login page
- Recordings failing to play after the recording feature expanded
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 →