MCS builds a detailed, continuous record of how every connection performs. Until now, seeing that record meant opening MCS. The people who act on it, from the NOC to the account manager to the budget holder, spend their day somewhere else.
The HTTP API sends MCS results to the places those people already look. Anything that can make an HTTPS request and read JSON can use it: dashboard and BI platforms, service desk tools, customer portals, data warehouses, or a short script.
In the example, the London average looks healthy. The chart shows the half hour when it wasn't, and that is the half hour your users remember.
| Site | MOS | Jitter | Loss | Status |
|---|---|---|---|---|
| London branch | 4.31 | 4.7 ms | 0.02% | Good |
| Manchester | 4.36 | 2.9 ms | 0.00% | Good |
| Dublin | 3.71 | 18.6 ms | 1.20% | Warning |
| Home workers | 4.18 | 7.4 ms | 0.35% | Good |
The same results you see in MCS reports, delivered wherever decisions actually get made.
Show MCS quality results on the same screens as your infrastructure monitoring, so a jitter spike lines up with the change, the backup job or the provider fault that caused it. Attach the actual test results to the service desk ticket, not a description of them.
Carriers, MSPs and UC providers can show each customer the quality of their own service, or fill in the monthly SLA report automatically. A key only returns what its owning user can see, so if each customer has its own MCS account, each customer's key returns only their data.
Keep years of results next to the business data they explain, in the warehouse and BI tools your analysts already use. Summarise by time period on the way out, and page through long histories in manageable batches.
No SDK or special client to install. If a tool can call a URL, it can read MCS results.
The API is off until an administrator enables it. Create a key for each tool or person that needs data, restrict it to known addresses, and set it to expire if the need is temporary.
One HTTPS request, using the same selections as MCS reports: test type, time window, source address and other report filters, as individual tests or summaries by time period.
Results come back as JSON, with paging for large pulls. Load them into a dashboard, a report, a portal or a database, on whatever schedule suits you.
# The last 24 hours of VoIP results from one address
curl -G "https://yourserver.example.com/myspeed/api/v1/data" \
-H "Authorization: Bearer mcs_ab12cd34ef56_..." \
-H "User-Agent: Mozilla/5.0" \
-d plugins=voip \
-d last=1 -d lastunits=days \
--data-urlencode "adv=[gbl:ip=1.2.3.4]"
Filters use the same syntax as MCS reports. Large result sets are paged with offset and limit.
{
"meta": {
"count": 1440,
"returned": 500,
"offset": 0,
"limit": 500,
"truncated": true
},
"data": [ ... ]
}
Each record in data carries the same fields you see in the MCS tabular report.
The API was built for organisations where the security team has the final say. It adds no new way to change anything in MCS, and nothing is reachable until an administrator decides it should be.
It follows the same principles as the rest of the platform. See how MCS is secured.
The HTTP API gets results out of MCS. Two other interfaces let your own systems put testing in motion.
A single URL creates a reservation for an existing MCS work order, and another returns existing reservations as JSON. Your provisioning or CRM system can issue a pre-installation network test to every new customer, without anyone opening MCS.
Publish a browser test and embed it in your own portal instead of hosting it on MCS. Runtime parameters let your page set test options and read progress and results from JavaScript.