I'm looking for an SMS gateway to send text messages over an HTTP interface.
However, some SMS gateways do not allow to set the sender ID, and those who allow it either require the user to prove that the sender ID is his own mobile phone number, or they manually check each sender ID to prevent SMS Spoofing.
For my application, however, I need to be able to set the sender ID as part of the HTTP request. Depending on the number of users, I might have thousands of different sender IDs, and I cannot authenticate or review them separately.
The purpose of my application is completely legal, as is the reason why I need to be able to send spoofed text messages.
Edit:
It seems that bulksms.com does allow what I need as soon as they trust the user to some extent. If you know of other gateways which allow setting the sender ID dynamically, please let me know.
It seems like the gateway you suggsted does let you set the sender ID. From their FAQ :
Is it possible to use the "sender id" parameter?
Setting of the Sender ID can be enabled after your initial credits
purchase. Sender Id requests are processed manually and thus we
suggest you request a sender Id change within office hours for a swift
response. Giving you full control of your sender ID, is only available
after you have been a regular and trusted user. Sender Id can also be
set via http request and email to SMS.
I finally settled with Routo Messaging, and the experience so far is very promising. They let you set the sender ID as soon as you have made your first payment, and if you describe them the reason you need it, they let you set the sender ID even on the free test messages you get when signing up on their website.
Disclaimer: I am not affiliated with Routo.
Fogmo offer an API for this very purpose.
Related
It seems that, recently, Amazon changed its flow to send test SMS messages (to a US number):
You can only successfully send SMS messages to numbers added to SMS sandbox.
To add a phone number to the SMS sandbox, you have to first specify an origination entity
In the US, only originating numbers are supported
SMSs can only be sent from toll-free and 10DLC, both of which require registration due to recent changes (9/30/2022) in carriers' policies.
Registration requires providing company information.
The above makes it next to impossible to test sending SMS if you don't have a company (or if your company is unwilling to undergo the phone registration process). Is there a simpler way to do this or am I missing something?
I have a high level architecture question:
I have a django app where users can send out sms to their contacts (telephone numbers, not users of my app). I am trying to implement a system where if someone replies to a specific text, such reply is forwarded to the user that started the thread.
I implemented an inbound webhooks to receive sms but I am now facing a problem: how do I know which text is a reply replying to? I can't seem to find any type of id in the sms inbound request and I am now starting to fear that this is just impossible.
Any idea? Should I try to use "Conversations"? Would that solve my problem and if so, how should I go about it?
Any suggestion?
Twilio developer evangelist here.
You cannot get the message that a user is replying to, because that doesn't exist in SMS. SMS messages are simply chronological. To test for yourself, open your SMS app and try to reply to the second to last message from someone.
You have a few options to try to tie a reply to a specific message:
Only ever send one message to be replied to at a time. Once you receive a reply to one message (or there's a timeout of some sort), send the next one.
Have the user enter a message identifier in their message. You can then parse the identifier out and associate the reply. This is not very user friendly and they may forget or get the wrong identifier in the message
Use multiple numbers to send the messages. So, if you have an active message you are waiting for a reply to, use a different number to send out the next message. You can then associate the reply based on the number the user replies to.
The last option is my preference since it doesn't affect the messages you can send at any time and doesn't require extra work on behalf of the user. It does require extra work to build a number pool and do the work to associate messages with sending numbers.
I want to build an in-app chat application without any login.
So, the user communicates with the program (the backend), not with other user. So, it's a chatbot.
My question is: How to identify the user? Should I just log the IP address? Or, should I generate a random ID on server? Or, should I just generate it on the client?
As I understand, the purpose of identifying the user is for the server to keep track of who is sending the chat message and to send back the response to the appropriate client (user). IP address can't be reliably used as a way of uniquely identifying the user because of numerous reasons (it is a separate topic). One example of it would be this - A small company routes all the outgoing traffic from its office network via a single router that has a single IP address. In this case, the requests coming from different employees of that company would have same IP address as detected by the chat server. So it can't distinguish between these users.
The idea of generating unique identifier on the server for each user can work. A UUID or a JWT or something similar can be used to generate the id when the user initiates the chat for the very first time. This ID needs to be passed back to the client so that clients (users) can send the subsequent chat messages using the same ID. Thus, in this model, the client would need to have a place to store this ID so that it can keep passing it back to the server in its chat messages. Now the problem can happen when the client loses this ID. How can we recover from this situation? The answer would be similar to the approaches being used when someone loses their password. There are several recovery mechanisms such as sending the reset link on the trusted email address or sending it on user's phone as a code or generating a recovery key which is different from the ID and emailing it out to the user which can later be used to reset the ID. Basically, there should be an alternate and secure way (recovery flow) to identify the user if the ID is lost.
If the ID is generated on the client side, that can also work as long as all the clients are able to generate the ID that is guaranteed to be unique. Clients can pass in the generated ID to the server and server can check if it is already used and send a retry message to the client if it finds that it is already used. Or if the clients are using some hardware that has unique serial number and that serial number can be used to generate the ID.
In either cases, all the requests must pass in the ID to the server so that server can do the identification.
Hope this helps!
I am using AWS Cognito User Pool for user sign up. I am using phone number as the attribute and I have set up verification of mobile number and enabled Multi-Factor Authentication.
I get messages from AWS and its getting verified and everything is working fine. But the sender of the message is "AXNOTICE".
I need to change "AXNOTICE" to my business id. I tried changing "Default sender ID" in "Text messaging preferences" of SNS Dashboaard but this didn't work.
Please let me know whether this is the correct place to change or do I need to change somewhere else.
Any help is appreciated.
I know this is late, but maybe useful for someone who is sending SMS where SenderId is allowed (e.g. UK):
It is possible to set a default SenderId in Simple Notification Service(SNS) which will then be used by Cognito when sending SMS.
Open SNS
Expand "Mobile" menu and click "Text Messaging (SMS)"
Scroll down to "Text messaging preferences" and click "Edit"
Set "Default sender ID"
Click "Save Changes"
Cognito will now send the SMS using the specified SenderId.
(Note, things may have changed since this question was answered it seems India does allow SenderId, but requires a reserved SenderId to be used, which is expensive ~£800/month. See https://docs.amazonaws.cn/en_us/sns/latest/dg/channels-sms-awssupport-sender-id.html
Some countries do not allow SenderId: https://docs.aws.amazon.com/sns/latest/dg/channels-sms-originating-identities-sender-ids.html )
AWS currently does not support custom sender id in some countries to find the list of countries that are supported by aws click on the below link
AWS custom sender id supported regions
I am working on django and sending emails to multiple users at once. in the given scenario it only tells me that if it has sent or not.
I want to display the report of same page that how many emails has sent to user successfully and how many not. more if i want to get details why email has failed to sent.
How would i do such things via SENDGRID APIs.
There are two options that I know of:
Connect to SendGrid Event Webhooks and start parsing events for every email to flag ones that were not sent. I believe you can configure SendGrid to only send certain events, so if you're interested in bounces you don't need to worry about handling all events.
The second option is to use a service like sendwithus which will connect to your SendGrid account on your behalf and track all bounces/opens/clicks for you and provide a simpler API/UI to view the data. I believe they do this via SendGrid's webhooks, so it's effectively the same solution but written for you.
Happy to elaborate on either, I've used both before.