I’ve had an account for a couple of years but just had a recent outage (issue on my side) where my device was no longer registered. So I’d like to set up monitoring for my registration status. I saw on the Main Menu of the VoIP.ms Home page that there is a SOAP/REST API. I downloaded the WSDL set up password, IP address and enabled API on my account. I tried calling getRegistrationStatus using Postman, but I got a 500 Server Error “Function ‘getRegistrationStatusRequest’ doesn’t exist”. So my questions are, is this API current? Is there any additional/updated documentation, other than the sample code on the Main menu, that shows how to use the API?
1 Like
You should probably open a support ticket and ask VoIP.ms support team directly.
When I was working on MMSGate2, I originally tried to use the SOAP interface. I found some issues with the interface and missing parts of WSDL missing. I did open a ticket, but it is considered beta and response is very slow. In fact, one SOAP ticket I submitted 13 months ago is still listed as pending. I recommend just use REST/JSON. It might look like this:
curl “https://voip.ms/api/v1/rest.php?api_username=$APIID&api_password=$APIPW&method=getRegistrationStatus”
Thanks for the reply. I did open a ticket, just to see what they say. I tried using the REST endpoint and after I changed the POST to GET, I got a response. Although the response was 'Invalid credentials". I changed the password to remove any special characters, I tried using my VoIP.ms username (email address) and I tried using my SIP Username (6-digit number), and still get invalid credentials. I’m not sure what they want. Any suggestions?
The ID is the email address you logon to https://voip.ms/. However, the password is different. It is the password you set at https://voip.ms/m/api.php. If there are any special characters in the password, be sure to encode them, as in ‘+’ becomes %2B. You can use https://www.urlencoder.org/.
+1 to @RVgo4it on the password, and one detail that confirms it: VoIP.ms returns a different status (ip_not_enabled) when the credentials are good but your source IP isn’t on the allowed list. So invalid_credentials specifically rules out the allowlist and points at the username/password pair. The URL-encoding tip is worth taking seriously too; an unencoded + or & in the API password fails in a way that looks identical to a wrong password.
Two things that will bite you right after that:
getRegistrationStatusneeds anaccountparameter naming the sub-account, e.g.&account=123456_myata. Without it you get a different error, so don’t read that one as the credentials problem all over again.- The allowed-IP field on that same API settings page accepts a hostname, not just a literal IP. Since you’ll be polling from home, put a dynamic-DNS name in there once and it keeps working when your address changes.
One caveat for whatever you build on top: register_next comes back with no timezone offset (e.g. 2026-09-18T14:44:11), so don’t assume UTC when you compare it against now(). It appears to be Eastern. That one cost me a wrong answer earlier today.
For the monitoring itself: we build an (unofficial) MCP server that wraps the same REST API, so the check can just be asked in plain language instead of scripted. Against my own account:
Same getRegistrationStatus call underneath; it just saves writing the polling and the parsing. It’s at voipms-mcp.ecliptical.io if that’s useful. We’re not affiliated with VoIP.ms.
I think the combination of changing the password and switching to use the login username and immediately doing another API call is what bit me. It’s now working. I appreciate the help.
The API does appear to be current, but getRegistrationStatusRequest suggests you may be calling the SOAP method incorrectly. VoIP.ms still documents getRegistrationStatus() in its API examples, and its current status page shows the REST API as operational. I’d compare your Postman SOAP request against the downloaded class.voipms.php example, especially the SOAP action and request structure.
This is tangential, but certainly related.
As a medical clinic, we obviously need reliable connectivity.
I had the same idea as you do, JupiterOne, of monitoring the lines via the API or portal’s registration status. However, long before attempting to set up the API auth, I had been watching the status on the portal.
[ Our lines do go down about once every two months, but almost always it’s on our side because we use ATA boxes. When the phones and FAX stop working, the fix is to just power cycle them. FYI - there is no pain medication available for ATA problems. And trying to keep an old-school, audio-modem FAX and Cisco SPA box working is as much fun as a root canal without anesthesia 
]
The portal’s registration status is very inconsistent.
It can show no registration found when devices are working fine - this happens frequently. It is rare however, to see registered when a device actually isn’t - but that happens too. 
Recall that all these connections have a ‘next connection time’ (mouse over the ‘i’ icon to the right of the subaccount’s registration status). So there is at least that potential delay. Power cycling a device can take upwards of several minutes before the status changes. (Yes, Dear Canadians, clinical evidence proves it can be that slow … 
)
That’s the reason I didn’t pursue the API. Without seeing the relevant code base, we can still guess that the registration data sent to the portal is sourced from the same place as the API would be.
Good luck - now I gotta go figure out why our FAX machine isn’t sending outbounds … oh, now where did I leave my bottle of Excedrin Extra Strength?
ciao,
Howard in North Florida
Thanks for the reply. Currently I have no monitoring on this little used phone attached to the ATA. I have had an issue only twice in about 3 years and both times the issue was on my end. I don’t mind if get false negatives as checking is fairly easy. But even though the phone is used rarely, when it is needed it is important, so I’d like at least something. I haven’t implemented anything yet so we’ll see how it goes.
I’d try the REST endpoint before spending too much time with the WSDL. getRegistrationStatus is still listed as an available API method, and there are examples using it to monitor subaccounts. The 500 error you’re getting with getRegistrationStatusRequest makes me wonder if Postman is calling the SOAP method name incorrectly rather than the API method itself being unavailable. I’d test the REST call first and see what response you get.
I ran into an issue with an ATA device of mine going offline. It is possible to use the VoIP.ms API. However, it may also be possible to check the ATA device directly. I use Obi200 ATA. I also use Linux. As an example, below is at script I use to check my ATA device every hour. For a different device and/or OS, it will be very different.
#!/bin/bash
# need to install libxml2-utils
# $1 is SP number. $2 is string to search for
# FILE=/tmp/obimon$1.mon
XMLFILE=/tmp/obi$1.xml
wget -O $XMLFILE --user=admin --password=adminpw http://192.168.1.8/DI_S_.xml
STAT=$(xmllint $XMLFILE --xpath "string(//object[@name = 'SP$1 Service Status'] //parameter[@name = 'Status'] //value/@current)")
if [[ "$STAT" == "*$2*" ]] ; then
echo Found $2 in "$STAT"
else
echo $2 not found in "$STAT"
echo Status for SP$1: $STAT | mailsend -to ......... etc.
fi
rm $XMLFILE
The strange thing is that my ATA didn’t go offline. I have a Unifi network controller (UDM-SE) and the ATA is also from Unifi (Ubiquiti). When I was experiencing the problem, I could pick up the phone, get a dial tone, dial a number and it rang (on my side). Everything sounded normal, but the destination phone number I was calling (my cell phone), never actually rang so the call wasn’t really going through. Eventually when I started looking at the VoIP.ms side, I noticed that my device was not registered. I opened a ticket with Unifi and although they couldn’t pinpoint the root cause, they did say the issue was on their (my) end, not VoIP.ms. Rebooting the entire console immediately fixed the issue. So that’s when I started this journey into seeing if monitoring my registration status could help in catching the issue early, if it ever happens again.