Kannel-like API
In addition to the regular JSON API, it is also possible to submit messages via a mechanism similar to the Open Source SMS Gateway "Kannel".
Submitting messages to Kannel involves sending a GET request and the parameters of the message as various query string fields.
For further insights into the Kannel interface check the Kannel User Guide.
Not an actual Kannel, only a Kannel-shaped-object
This Kannel-like API is in fact not an actual Kannel, but instead just another route on the API specified in the regular JSON API.
This means there is some differences, and therefore existing Kannel integrations might need some adapting before they can use this Kannel-like API.
This also means that the API is subject to some of the same ratelimiting and firewall.
The Kannel-like API is available at https://api.nuudaysmsgateway.dk/v1/sms/submit/kannel.
Authentication
The standard Kannel HTTP interface expects the authentication in the form of username and password, this meshes poorly with our token based authentication.
Instead the API accepts the token either of the fields, with a preference for password over username - but allowing username for compatability reasons.
If the token is supplied in the password field, whatever value (if any) in the username is ignored.
Supported Fields
We support the following query string fields:
All fields has to be propely percent encoded (commonly referred to as URL encoded), to avoid breaking the parsing if any characters with special meaning in a URL is somehow included.
text
The text of the message.
Ensuring the correct percent encoding can be difficult as the text is be intepreted as percent encoded bytes, the API will then use the charset to decode those bytes into text.
More details about the proper handling of text encoding is described in the charset section.
to
The recipient of the message.
from
The sender of the message.
coding
The Kannel specific data coding values, that control how the message should be send via the lower-level connection. Supported values are:
0: for GSM7, called 7-bit.1: for binary messages, called 8-bit.2: for UCS2, called unicode.
charset
Defines the encoding used to parse the message text. The primary options are:
utf8utf-16bewindows-1252
When submitting messages using utf-16be, then the text should be encoded to bytes using the same encoding, often resulting in many null bytes in the submitted values when using a western European character set.
When submitting binary messages it is best not to include a charset at all.
Below is a comparison of how a text should be encoded for the different charsets:
udh
The User Data Header of the short message, should be percent encoded from bytes.
validity
The time in minutes the SMS remains valid for. If unset it will use the SMSC default of 5 days.
mclass
Used for sending different types of messages to the devices, the default is 1.
Supported values are:
0: For "flash" messages1: For "normal" messages
account
A client provided string reference, often used to indicate the billing account for a specific message, but can also be used for a per message reference.
Delivery Report Callbacks
Our Kannel-like API does not currently support delivery reports in the Kannel format.