I just got an alpha invitation to try out the 46elks SMS API. These are my notes.
My Own Summary of The API
- Several numbers can be tied to your account
- RESTful HTTP API (with version in base URL) with JSON responses
- BASIC HTTP Authentication
- HTTPS
- Simple GET web hooks / URL callbacks (per account and per number) for inbound delivery with message payload as URL query parameters
Nice
- “Splitting and joining multi-part SMS messages are automatically handled by the API.”
Opportunities
Delivery Notifications
I’d like to be able to know if a text (SMS) has been received by the target recipient(s). We used this when we had several people “on standby”, if the first person was not reached withing one minute, we moved on trying to contact the next one.
A callback URL for delivery notifications (tracking) would be perfect.
Error Messages
The API docs doesn’t mention error codes/messages or what types of validations are carried out on the backend.
Non-plain Text Content
VCards is the type I’ve ran across previously.
Other Notes
Character encoding is said to be UTF-8 which is fine. The docs should perhaps be more clear on this since they accept parameters with GETs (and in URLs, there is not standard way of telling what character encoding is used).
I’d prefer if the URL callbacks used POST (and JSON payload). GET URLs are limited and even though not many users tend to send 1024+ long texts, my mother does and that would risk being cut off somewhere down the line (or software stack).
Delivery limits – how long will 46elks hold my messages when my server park is out? How many attempts at delivery will 46elks make?
The documentation should have perhaps used https in the examples.
Timeout limits for replying to a message should perhaps be in there, as well as the option to turn this feature off. If my service somehow is throwing error messages out, I’d prefer them not being sent to my clients.
Bottomline
As an alpha preview – this is great and looks really nice and convenient to use. A complete (send and admin account) interface can be written using HTML+JavaScript only. As expected, there are a couple of things missing from the API, such as cost information/account balance and perhaps type (prepaid, invoice, …).
Update: I put out the quick hack files I used to try the API on GitHub.
