SMS Gateway API from 46elks

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.

CACert Assurer

CAcert Assurer Badge

CAcert Assurer

Sedan ett par minuter tillbaka är jag godkänd som CAcert Assurer. Det innebär att jag kan intyga identiteter och dela ut poäng till CAcert-medlemmar (så att de kan få fler poäng och bättre certifikat).

Målet med CAcert är att genom en transparent process och ett web of trust, bygga upp certifikathantering som är fri och likvärdig den traditionellt “kommersiella” (och grymt exploaterade) hanteringen. På kort sikt vill man se till att bli tillräckligt godkänd för att root-certifikatet skall distribueras med Mozillas alla produkter, t ex Firefox. När det målet är nått kan man alltså utan kostnad skaffa ett SSL-certifikat för sin webbserver och använda HTTPS utan att vara tvungen att betala avgift för att erhålla ett certifikat signerat av en betrodd CA.

En högst parentesaktig reflektion är att Debian borde vara med på detta som hökar kan jag tycka. De har ju fört seriösa diskussioner om en egen topp-nivå-domän (TLD) och DNSSEC:a en egen root-zon (om jag inte förstått det fel).