The SendHub API: Heroku for Twilio(blog.sendhub.com)
blog.sendhub.com
The SendHub API: Heroku for Twilio
http://blog.sendhub.com/post/18954293816/api-launch
42 comments
The main issue is what happens when you want to receive a reply to your message - you're going to have to build an inbound endpoint and process those requests. Then how do you know what you sent that contact in the past or what they sent you? We fix those kind of problems and it's just one call for each of them.
That sounds good. I should say that a) I haven't thought about this enough to produce working code, I was just offering my impressions after reading your website; and b) it's not obvious that this is a core value point (for instance, there's no code sample for inbound on the developer page).
Based on the other comments, it seems like I'm not the only HN reader who doesn't really understand your value from your website.
Based on the other comments, it seems like I'm not the only HN reader who doesn't really understand your value from your website.
Thanks, that's great feedback, the developer page is definitely in v1. You can see the send and receive functions on our getting started guide: http://apidocs.sendhub.com/GettingStarted.html#viewing-the-i...
c) this would take a developer like 2 hrs to build... NEXT!
When are we going to stop referring to companies as the X of Y? It's incredibly confusing and detracts from the company's message.
Or am I alone in thinking this?
Or am I alone in thinking this?
X of Y is pretty powerful when it makes sense. In this case it's tough for me to parse.
Edit: For me, I see EC2 as virtualized servers, and Heroku as Application management. I see Twilio as currently on the same playing field/complexity as Heroku (compared to say, hosted Asterisk)
Edit: For me, I see EC2 as virtualized servers, and Heroku as Application management. I see Twilio as currently on the same playing field/complexity as Heroku (compared to say, hosted Asterisk)
Yeah that was my feeling too. I mean it's great to have a one-click application to get up and going, but Twilio is about the easiest API i've ever seen, so it's not exactly rocket science.
We love the Twilio api too, but you still have to write a lot of code to make it fully functional for your app, our api takes a lot of that need away. For example, what happens if someone calls the number you send your text from? We have settings and options for that.
All the best. And I was (and still am for lots of things) and EC2 user who is now heavily using Heroku, but just didn't get it at first. That's where I am with this right now. I love Twilio, I got it and had an entire application (SMS send/receive, call receive, etc) up and running and debugged in an afternoon. I think that you might have that resistance among people who have used Twilio already.
Thanks, great feedback. We're definitely focused on developers not yet using Twilio for their apps or don't have the time to manage in and outbound messaging on their current apps.
I can't tell if this is just a simplified passthrough API for working with Twilio or if there is something more to their services.
Twilio's API is already pretty dead simple.
Twilio's API is already pretty dead simple.
We add a lot of extra features on top of the twilio api, like: send and receive messages, context for conversations, scheduled messages and contact management.
1) send and receive is built in API
2) just keep a db log - simple
3) omg - set an int(12) of time() when you want it sent in DB... run a cron script, check if currentTime>sendTime... send!
4) meh - simple enough
I don't get how companies like this get funding - so simple and do nothing imo except provide another point of failure.
2) just keep a db log - simple
3) omg - set an int(12) of time() when you want it sent in DB... run a cron script, check if currentTime>sendTime... send!
4) meh - simple enough
I don't get how companies like this get funding - so simple and do nothing imo except provide another point of failure.
Thanks for the feedback.
1. You have to build an endpoint and process the inbound requests, that takes a good deal more engineering time than making an api call to check for them.
2. This gets complex when you're sending messages to users in the context of groups an individuals. it's not a big problem but you'd still have to code it.
3. That sounds simple but doesn't account for things like timezones.
1. You have to build an endpoint and process the inbound requests, that takes a good deal more engineering time than making an api call to check for them.
2. This gets complex when you're sending messages to users in the context of groups an individuals. it's not a big problem but you'd still have to code it.
3. That sounds simple but doesn't account for things like timezones.
1) no it doesn't - i've done it plenty of times with twilio - very simple
2) ok...
3) WATCH OUT - TIMEZONES!!!!!!!!! TIME = SERVER_TIMEZONE + (USER_OFFSET)... or you can locally change the time zone of the whole account to their local one... come on... easy.
A lot of other comments are bashing you guys, and I'm not interested in doing that. Of course, I have some questions that I often ask myself when I'm brainstorming and perhaps they will help you as well.
1. Is this a product or a feature? Realistically, what's stopping Twilio from providing these features if you prove that there is a market? Or what if someone implements this functionality as an open source gem out of spite? (See: Growl's painful movement away from free)
2. What is your unfair business advantage? And why you instead of someone else? Do you have years of experience working with Twilio or SMS in general? Are you super wealthy or connected politically in an advantageous way? Are any of your employees or founders former Twilio folks?
3. Is there a market here big enough to justify the existence of your company? Even if your CAC is low and your LCV is high, are there more than 1000 people that need this, and are they willing to pay a premium for what you offer?
I'm genuinely curious what kind of customer development you've done to demonstrate that you're solving a hair on fire problem. I'm had no idea there were so many Twilio SMS apps under current or future development.
1. Is this a product or a feature? Realistically, what's stopping Twilio from providing these features if you prove that there is a market? Or what if someone implements this functionality as an open source gem out of spite? (See: Growl's painful movement away from free)
2. What is your unfair business advantage? And why you instead of someone else? Do you have years of experience working with Twilio or SMS in general? Are you super wealthy or connected politically in an advantageous way? Are any of your employees or founders former Twilio folks?
3. Is there a market here big enough to justify the existence of your company? Even if your CAC is low and your LCV is high, are there more than 1000 people that need this, and are they willing to pay a premium for what you offer?
I'm genuinely curious what kind of customer development you've done to demonstrate that you're solving a hair on fire problem. I'm had no idea there were so many Twilio SMS apps under current or future development.
Thanks for the questions, I'll do my best...
1. The API is certainly one of our suite of features, you can also use SendHub via the web or any sms enabled cell phone. We expect to see more competition in the space and will be doing our best to contribute to open source ourselves.
2. A lot of our users have tried other SMS products and found them to be a poor experience - based on the feedback we get. We try to spend our time focused on building the best possible product and let that, rather than our backgrounds, do the talking.
3. We believe so, and our initial sales are reflective of that.
1. The API is certainly one of our suite of features, you can also use SendHub via the web or any sms enabled cell phone. We expect to see more competition in the space and will be doing our best to contribute to open source ourselves.
2. A lot of our users have tried other SMS products and found them to be a poor experience - based on the feedback we get. We try to spend our time focused on building the best possible product and let that, rather than our backgrounds, do the talking.
3. We believe so, and our initial sales are reflective of that.
New category "SaaSaaS"? (Software-as-a-Service)-as-a-Service
or platform as a service?
Isn't Twilio is that platform?
I think the same could be argued for Heroku and EC2 - no?
I strongly believe in the concept of "outsourcing" components of an operation in order to specialize more, but is Twilio's API really that hard to use?
We think the Twilio API is great but there's lot of features you might need for your app that aren't built in and that SendHub's api provides, for example: we have an inbox with threads so you don't need to build an endpoint to receive messages and they can be kept in context.
"Heroku for Twilio" is painfully opaque. How would anybody know what you do if they are not already PaaS hipsters?
I've done a significant amount of development with Twilio, and I can say that I do see a need for a service like this. Developing conversations with Twilio is a pain, and requires a bank of phone numbers. A service like this can pool phone numbers among apps, and result in savings for everyone.
The question is, how many apps need to implement conversations for Twilio?
The question is, how many apps need to implement conversations for Twilio?
This may be answered the developer guide, but what's up with the rate link in every message sent? I get that it's for recipients to gauge whether or not the sender is spamming, but where's the option to not include it?
If using this on top of an app I'm building, chances are I don't want to refer users to SendHub each time I send them a txt.
If using this on top of an app I'm building, chances are I don't want to refer users to SendHub each time I send them a txt.
We do this for a few reasons: 1. you can send msgs longer than 160. 2. You get realtime feedback on the msgs. 3. It helps to prevent spam.
We don't allow the removal of the links but you can control the landing page with your name and avatar and our paid plans include complete branding of the page.
We don't allow the removal of the links but you can control the landing page with your name and avatar and our paid plans include complete branding of the page.
Understandable. Thanks for clearing that up.
I guess I should also note that this is the dealbreaker for me. I've been building using the Twilio API for a while now and this would've been a bit of a timesaver for a new app, however I can't get past having to refer someone to a page that bears no importance to my end-users other than them being able to flag me for spam (which if they subscribed to me, is unlikely). Good work on this though!
One (hopefully) final question I would like to ask: what happens if my message body is say, 155 characters long? Will the rate link be appended to the end and another message be sent with it? Just seems a little roundabout
We truncate longer msgs, and the link leads to the full msg. The link allows you to get realtime feedback on your msgs which a lot of ours users find extremely valuable. We'll also be adding some more features to the landing page, which you can brand, so SendHub is largely invisible in the process.
Curious...what throughput do I get when I use your service? Twilio limits you to 1 SMS / second unless you get a short code (30 SMSs / second) or otherwise use multiple numbers.
Do I get any benefit from you guys regarding this?
Do I get any benefit from you guys regarding this?
You can ping us at support [at] sendhub.com and we'd be happy to talk through your options.
An API for an API. How meta. I would have gone with "The SendHub API: GroupMe for Twilio". Heroku for Twilio doesn't make sense to me.
Question: How many numbers can a plan have?
Question: How many numbers can a plan have?
We give you 1 number per plan, but always happy to talk through individual needs: sales [at] sendhub.com or feel free to ping us on live chat on our site.
More than API for an API, to me, this service sounds very valuable for businesses for their SMS communications/marketing needs.
Great docs - looks super simple to get started, will definitely try this out. Do you support CORS out of interest?
Thanks, we didn't build the API with CORS in mind but if you have suggestions or use cases, we're always open to making it easier for developers.
Actually, a few people have now asked about this, if you'd like us to add it: please send an email to support [at] sendhub.com or text us: (650) 830-5662.
to a single line (the first code is from Twilio's page). If that's not what you do, you should make it clear what you do. Otherwise, I wonder why I'd pay (and add a point of potential failure) to reduce a single line of code to a different single line of code. Also, it looks like I'd lose the inbound SMS feature of Twilio.
Gosh, this sounds like I'm bashing your app, which I don't mean to do. You're YC-backed, so I'm sure the issue is the content on your website not representing your actual value. Hope this helps you align the two.