Sending Two Factor Authentication (2FA) codes by SMS API
SMS text is still preferred and easiest way to send Two Factor Authentaction credentials. Here is how to do it with API.
We have discussed the topic of two factor authentication previously several times, here regarding voice call ( https://datatechlabs.com/posts/56/two-factor-authentication-api-with-phone-call ), here in general ( https://datatechlabs.com/posts/48/two-factor-authentication-with-sms-and-voice-calling ) and here regarding one time passwords: https://datatechlabs.com/posts/32/usecase-one-time-password-generator-for-application-security
Now let's see how to do with SMS, simply by using our API. In general, sending SMS is as simple as constructing this simple request:
POST /sms/send
{
"to": "recipient",
"from": "sender",
"content": "hello, World!"
}
In this simple example above, the API will just send a hello, world!
message to recipient
. There are, however, ways to have more control about the sending process, like, for example: getting to know if the message was delivered or not, or sending non-latin encoded texts:
This request will ask for a delivery receipt (DLR) after the message was delivered:
POST /sms/send
{
"to": "recipient",
"from": "sender",
"content": "hello, World!",
"dlr": true
"dlr-level": 3,
"dlr-url": "http://server.host.com/path",
"dlr-method": "POST"
}
Now, upon successful delivery, the API will do a HTTP POST to the address of the server specified in dlr-url
and report on the on the success of delivery. The values of dlr-level
attribute are integers, where 1 - means SMS-C delivery report, 2 - means endusers terminal delivery report and 3 means both of them.
In the case we need to send non-Latin characters, we can set desired character set with coding
attribute:
POST /sms/send
{
"to": "recipient",
"from": "sender",
"content": "hello, World!",
"dlr": true
"dlr-level": 3,
"dlr-url": "http://server.host.com/path",
"dlr-method": "POST",
"coding": "UTF-8"
}
Note, however, that most SMS carriers actually charge per bits of message sent (see https://datatechlabs.com/posts/13/anatomy-of-a-short-message ), i.e. only the messages with are 7-bit encoded (ASCII) are allowed to be 160 characters long before they are split into multiple segments.