You're making the mistake laypeople often make which is that the resources disposed to do X were fungible enough to do Y as well. What if this were interns or contractors? Engineers in test? An engineer on sabbatical?

(Former Twilio API engineer here - you might like my Go library, which is reasonably feature complete and I have been using in production for some time, https://github.com/kevinburke/twilio-go. In production here: https://github.com/kevinburke/logrole)

I'm curious about the comment on API versioning. If it instead had the string "/v1/" embedded in the URL, would this be preferable to you? Which APIs do you feel are in need of updating?

Disclaimer: former Twilio PM.

So pointing out the API versioning scheme was disingenuous. It's as good as any other scheme and is probably necessary for backwards compatibility... it just seems old. I'll divide my short feedback into three categories:

API Features that I feel should be there but aren't:

- CRUD operations for Copilot

- Bulk operations for SMS/MMS - seriously one request per?

- CRUD operations and better access for logging and billing in general. The UI does not suffice.

User Interface:

- You did a huge redesign ~2 years ago that was frankly underwhelming. It added some SPA like functionality splattered through out the site, and many of the operations, like adding numbers to a Twilio Copilot service, became slow and buggy.

- Good artists copy and great artists steal. SaaS products at GCP, AWS, Stripe, aren't necessarily perfect but can all be drawn from to create a better product. I honestly feel like most of the innovation at Twilio clocked out ~4 years ago and now its just maintenance work and annual reboots. Though this project shows innovation its far away from the core concerns of customers. We know how to use the platform already...

Generic:

- Better documentation

- More transparency for how carriers handle SMS once Twilio passes it off

- More transparent pricing. I.e. if I send a 1600 character text I'm getting billed ~10 times or whatever - not great.

EDIT: Finally because Twilio is a billion dollar business I hold it to a much higher standard then I did ~5 years ago. I don't mean to discourage hardworking employees who mean well, just as a former employee of a not insignificant customer I have some residual entitlement and frustrations.

>- You did a huge redesign ~2 years ago that was frankly underwhelming. It added some SPA like functionality splattered through out the site, and many of the operations, like adding numbers to a Twilio Copilot service, became slow and buggy.

Not only to the developer portal/backend, but to the documentation as well.

It went from something that was really straightforward and easy to use, to something that feels like you have to fight it to find what you want. I'm really curious what happened, or why this design decision was made.

It's honestly bad enough that imho there is space for somebody with a better UI/documentation to move in and compete on that.

Twilio now has a Passthrough API https://www.twilio.com/blog/2017/08/bulk-sms-with-one-api-re... to address bulk SMS.

Personally I'd love to see an improvement to the backend UI. I spent a good 5 minutes searching around for "twiml apps" yesterday, finally resorting to just googling it.

This seems like core functionality of the backend. Why is it not placed somewhere more obvious?

I did a Twilio side-hack this weekend with a full multi-user phone tree and password layer.

Spent more time trying to navigate the developer portal than programming but wrapped up in about three hours.

It’s a testament to both how capable the API is and how terrible the UX is.

The graphics look nice but the layout is inscrutable.

Agreed - documentation lacks in frustrating ways at times. For example the docs [1] for migrating to their new python client are still lacking despite cornering developers into upgrading (don't offer support unless you've upgraded).

[1]:https://www.twilio.com/docs/libraries/python/migration-guide

I haven't written any golang, but why would you want a native client, when using http directly is nicely documented? I've worked with providers that worked in part of the same space, but only provided native clients, not documentation for directly using http; that was a big pain because I was porting to a language they didn't support and I had to reverse engineer the client for the language we used to use.

For me, I'm happy that they haven't changed their api in forever, I'm still using them in the same way as five years ago, I don't need to change my code.

Hey out of curiousity what did you feel was tough in golang? I recently built an application that used twilio (heavily) in golang, and didn't seem to have much trouble.

The problem isn't with the REST interface Twilio offers necessarily but that ~3 years ago when I first got into Go + Twilio the third party libraries created had pretty serious flaws. For example they'd use the default http.Client which doesn't set proper timeouts and can lead to various issues. At that time I was unaware with such issues and struggled. A first-class library would alleviate these issues for people who are in a similar spot.

Please take another look, my library configures the default timeout to be 31 seconds (one second wider than the API timeout), and lets you pass in a context.Context for each API call. https://github.com/kevinburke/twilio-go

Perhaps a Hackathon project?