I am really hoping this feature is being worked on or is something being prioritized. Would it really take that much code to implement?
It makes it hard for me to use voip.ms in a normal way with friends. I have to explain to them my entire setup and it seems strange and is alienating. I want to talk with people about “look at the savings with voip.ms” and not “yeah, sorry it doesn’t have this feature that everyone else can normally do".”
I’m glad I’m not the only one who is using a voip.ms number as a main personal number (for 12 years now), and is running into friction like this. It’s becoming harder and harder to participate in the world with a voip.ms phone number. (Including many issues that are beyond voip.ms’s control, such as how many companies are becoming distrustful of VoIP numbers, and refusing to allow use of them.) The lack of proper group texts is an impediment not just for communicating with friends, but with vendors/contractors/etc. who seem to increasingly take for granted that they can loop in others as needed.
I may soon need to port my main number back to a regular mobile provider just to deal with the world. Though it would certainly be sad and annoying to lose the many powerful voip.ms features I use. 
It’s just a really great feature if they can add it. I wish I knew why they weren’t adding it, or if they are trying. If they can make texting as full-featured as a normal number, it would make it much more of an appealing option for many people.
Totally agree. Not sure why the company is not focusing on improving that. SMS/MMS are probably the most important basic functions for phones. Voip.ms still has a lot of holes: delays, MMS, international character support, etc. They always use the excuse that these issues are due to voip constraints. But other voip providers seem to have done much better.
I completely agree with everyone here. Group texting is a basic expectation in 2026, and the lack of it makes using a voip.ms number as a primary line unnecessarily difficult. Friends, contractors, and businesses all rely on group threads, and it is frustrating having to explain why a modern phone number cannot participate in something so standard.
At this point, I am genuinely starting to wonder whether voip.ms develops these features themselves or if they are simply a reseller passing along whatever the upstream provider rolls out. Every time there is a technical issue, the explanation seems to be “the upstream provider,” which makes it hard to understand what voip.ms actually controls.
This feature would make a major difference for those of us who want to stay with voip.ms, but the ongoing silence around it is becoming discouraging.
Yes. SMS/MMS needs some 
.
I agree. For some people, part of the reason they like voip.ms is because they can have different lines for different thing:
And if you use voip.ms, and then suddenly there’s a job related group text, it’s pretty impossible to deal with.
There’s a guy who made a voip.ms messaging app with an api call and people could ask that person to add the feature or just review the code with AI and even generate the code for that guy to add it in based on the metadata. I just don’t know if the metadata with the texts that the api pulls even have enough info to reconstruct that it’s a group text.
I created an issue on github to see if it was possible to just code this somehow, but apparently the api doesn’t allow it.
From Github:
JohnMertz left a comment (michaelkourlas/voipms-sms-client#300)
Unfortunately the MMS API calls still don’t support this. An example response for the getMMS call includes:
{"id":"XXXXXXX","date":"2026-06-30 12:34:56","type":"1","did":"1111111111","contact":"2222222222","carrier_status":"Information not available","message":"Message text...","col_media1":"","col_media2":"","col_media3":"","media":[]}
So no information on the other members of the group are included, only your number (the did) and the sender (the contact).
Likewise, the sendMMS call is documented to have the following arguments:
did => [Required] DID Numbers which is sending the message (Example: 5551234567)
dst => [Required] Destination Number (Example: 5551234568)
message => [Required] Message to be sent (Example: 'hello John Smith' max chars: 2048)
media1 => [Optional] Url to media file (Example: 'https://voip.ms/themes/voipms/assets/img/talent.jpg?v=2'
media2 => [Optional] Base 64 image encode (Example: data:image/png;base64,iVBORw0KGgoAAAANSUh...)
media3 => [Optional] Empty value (Example: '' )
dst is validated to only allow a single 10 digit phone number, so there is no way to actually send a single message to multiple people. When doing so in the web portal, it is just going to be making multiple identical calls with just the dst value substituted for each.
I don’t know whether this is a actually a feature that VoIP.ms could implement themselves. It is very likely the case that they integrate with another aggregator/carrier who take the information submitted via the API and actually transmit it as a properly formatted MMS via the carrier infrastructure. Access to this infrastructure is controlled, so not just anyone can transmit messages. If this is the case, VoIP.ms would be limited by what that carrier accepts and what data they provide for inbound messages. It would seem likely that this carrier would have the capability to transmit a list of recipients, in which case minor API and client changes could handle the treading and “reply-all” functionality of group messaging, but unfortunately we don’t have any way of knowing if that is possible.
As discussed in the forum thread, the best that users can realistically do is request the feature. Perhaps if someone does this, and is given details on the feasibility, they can include those details as a reply to the forum thread. Regardless, this is not something that can be solved within the app until the necessary API changes/additions are made. Unfortunately the VoIP.ms decision makers seem more interested in Microsoft Teams integration sigh.
For now, the best you can do is to convince your group chats to move to Signal or the like.
So I would be willing to pay to get texts (with no texts) just to inform me of who the other group members are so they could be consolidated into a group text in an app. Do others feel this way? Or is it just that voip.ms’s upstream provider can’t or won’t pass on the other group members, even with a charge?
{"id":"XXXXXXX","date":"2026-06-30 12:34:56","type":"1","did":"1111111111","contact":"2222222222","carrier_status":"Information not available","message": Group_Member_1_No_Text text...","col_media1":"","col_media2":"","col_media3":"","media":[]}
I know you are working on many different things to make voip.ms better all the time and I really appreciate your great company, the voip.ms team, and all that voip.ms offers.
If this isn’t a metadata limitation of all voip texting, and there’s any way to include more metadata so that programs could reconstitute group texts based on metadata, it would be wonderful to include this.
I know voip.ms focuses more on serving businesses that don’t use group texts, but for people who do receive group texts, the lack of metadata about the group makes it harder to respond to everyone in the group.
Even if a single text was multiplied by 5 to send to all group members, voip.ms has such great rates for everything it really wouldn’t matter that much.
I hope you see this and consider it for any future upgrades for voip.ms. Thank you!
Hey @sipper, thanks for tagging me on this. Unfortunately, the latest update from our carriers is that not all of them currently support group messaging. Supporting it halfway would just make it more clunky. We’ll keep pushing for broader support as things evolve!
Okay, thanks for pushing for it. I really love VoIP.ms, in large part because it’s got such reasonable prices and so many features. The lack of group texting is the one issue that really makes things harder for me and really, as soon as this issue gets resolved and group texts are possible, it will probably make VoIP.ms more attractive to many people who care about such texts.
Hello @DavidR,
I was just thinking, even if you do not implement the feature in your official UI, could you, on the API side, provide the information that is at least available (or best guess) from your providers?
That way, on the API side, developers and integrators could at least potentially have “more” information and you leave it to them to implement features with it or not.
So the responsibility would not be on you, but on integrators.
I mean, in many cases, half baked is better than nothing.
Just asking/throwing the idea.
Best regards!
The entire texting universe is overseen by the cellphone companies, who created texting. I believe that two of their goals when allowing texting by non-cellular numbers are:
• extract per-message and TCR revenue, and
• make the service inconvenient in ways that might frustrate people enough to prompt them to convert their number to a cellular number, such as:
— ineffective blocking of spam or unwanted senders
— blocking of messages that contain obscenities or drug-related terms
— no group messaging
— no receiving of a contact that was texted from a smartphone
Of course, my hunches may be wrong. If you know of any non-cellular texting providers that behave differently, I’d like to know.
I can understand the frustration. Sometimes it’s the small quality-of-life features that make the biggest difference in day-to-day use, especially when you’re trying to recommend the service to others.