Need advice about which tool to choose?Ask the StackShare community!
Tropo vs Twilio: What are the differences?
Tropo: Add Voice and SMS to Your Applications. Tropo is a powerful yet simple API that adds Voice and SMS support to the programming languages you already know; Twilio: Bring voice and messaging to your web and mobile applications. Twilio offers developers a powerful API for phone services to make and receive phone calls, and send and receive text messages. Their product allows programmers to more easily integrate various communication methods into their software and programs.
Tropo and Twilio belong to "Voice and SMS" category of the tech stack.
Some of the features offered by Tropo are:
- Develop for FREE- Pay when you're ready- Tropo is completely free for developers. Pay when you deploy and only for what you use.
- Feature Complete- Get all the features you want, today. Speech input, multi-language, and more.
- Amazing Support- Ask us questions 24 hours a day. Via the web or IRC.
On the other hand, Twilio provides the following key features:
- Phone- Phone Numbers API
- Phone- Convert Text to Speech and Play Audio
- Phone- Record Calls and Store Them
I am doing some research on WebRTC and would really appreciate speaking to anyone who has recently completed an integration or has a project currently under way. Hoping to gain feedback about tools used, what you liked, or didn't like, and anything perspective you might be willing to share about your overall project experience as it relates to integrating interactive, live-streaming content and audience engagement

I'm a bit biased, but I've always had fantastic experiences building with Twilio's tools and documentation. Years before joining Twilio, I started my own company with Twilio Video being a core component (it was a platform for online coaching), and as a one-dev-shop, I couldn't believe how easy it was. I now work here and get to help customer build quickly and effectively with these tools.
Some of the features I love include Video Insights for monitoring/debugging room and client device performance in aggregate or per session, the Compositions API for programmatically processing & exporting recordings in different formats, complementary products like Twilio Live that let you easily scale broadcast or livestream-style video experiences, the ability to store recordings directly to S3, and the integrated DataTrack API for exchanging & syncing data between participants.
Hello,
My app will be a live streaming app (like tango, BigoLive) An app developer asked me to choose a tech stack and a team. expected auditions from (Bahrain-KSA-UAE-Kuwait-Oman)
200 (broadcaster) at a time (minimum) (for 12 hours a day);10K watching the 200 (like 50 to 500) each live.
What servers are the best to use and give smooth high quality like Bigolive? For live streaming, and texting, and everything.
Which one is the best combination for my app? (Firebase, AWS, Twilio. Agora)
Thanks
Hey! We need an omnichannel inbox that's housed within Salesforce Sales Cloud that makes it super easy for our reps to respond to inbound communication (needs: clean inbox, provides historical context, etc.). We're a high-volume call center, and we get a ton of incoming SMS and email every day. We'd love a solution that lets us view all of that in one place — ideally Salesforce, as that's where our reps work, and we want to avoid needing them to switch between windows. Thanks!
if the inbound SMS are sales rep specific you could potentially have twilio fwd that msg to a google voice phone number which will in turn put an email in their inbox (so they're looking at 1 inbox instead of multiple places) Just an idea. Probably way off in left field compared to what you're thinking and I also invision. I'm not all familiar with MessageBird nor am I at all familiar w/ your data flow / business process. Would be happy to help brainstorm anytime! 10+ years experience on the sfdc platform
Check out Centro. We built this to solve this exact problem! We used tools like Twilio but wrapped it up in a application that runs on Slack.
Hello! We need to integrate an SMS gateway into our app for user phone verification. As we are just starting, we are searching for the most affordable/best price/performance option for SMS gateway to verify client phone numbers with the code, maybe you can suggest something between those two or maybe something else. We are planning to do business in Europe
Twilio documentation is very good and as a platform it just works. It's robust and reliable. We road-tested plivo and it wasn't anywhere near in terms of docs or support. In fact their support was terrible at replying to us. 48 hours to answer basic questions.
That's said, were also using sendgrid by twilio and that's not been pleasant . Their email builder appears to be react based but written by a team who don't understand react very well. That's a nightmare as yet

stackshare doesn't seem to have this in the stack list yet, but in my experience Twillio is attractive. It's good for basics, their acquisition of SendGrid gives them a bit more market share.. They are stronger at marketing to those that benefit them. That said from my understanding SendGrid leases the networks, channels, and lines. While their interface is friendly, their pricing suited for lower volume, you want to look at what they are using via an API, a contract, etc. Is it a more friend UI to a combination of others. What redunancies do to they have, try their support. It's not that Twillio is bad, it's about the volume, the use case, the liabiitlies you might have to your end-users if Twillio isn't the right choice. Another option is Bandwidth. You ask for affordable, Twillio is an option, but front end costs v/s the costs of support you'll need to consider. Bandwidth has more reliability but requires more engineering and more skillset. Another option that is worth considering, not the most affordable, but https://www.zipwhip.com/ have perhaps options that might be higher and the cost is relative. Wight costs, of support costs of integration, cost of scale, costs of a volume..