4 ms·

thanks for feedback! very well appreciated. Can you elaborate how we can improve on text encoding handling? For bulk sending, we consider ourselves a pure API

thanks for feedback! very well appreciated. Can you elaborate how we can improve on text encoding handling? For bulk sending, we consider ourselves a pure API and don't want to offer software tools to send bulk campaigns. However, our developer community is active building tools and mashups on top of our API for things like campaign management tools.

v21 15y ago
I'm not suggesting that you offer management tools, but an addition to your API that allows for specifying multiple recipients for a single message would probably be quite popular. It would also reduce your server load, as you would receive far fewer requests. Of course, this complicates sending back the status of the message, and with large volumes you probably have carrier-side rate limiting, so it would probably be asynchronous. Many sighs. But probably worth building at some point, for those that don't want to use SMPP. As far as text encoding - it's a hideous world, and I'm glad to forget the details. But you should probably give a link on your documentation to the GSM03.38 character set, and specify what happens if you include something that isn't on it, for a start. And maybe provide optional support for non-GSM03.38 encodings.