M
Mercurius API
Parlacom developer docs

Mercurius API

Parlacom API reference

Every Parlacom service — voice, PBX, DIDs, VoIP/M2M PINs, SMS, GPS and UPC — is exposed through a single HTTP endpoint. Pick a function, send the parameters, receive an XML/JSON response. All endpoints share the conventions below.

Start here

Session lifecycle — login → sessionid → refreshsessionid

Every Mercurius call is authenticated by a session. The very first API call your client makes is always login: you send the company plus the admin credentials, and the response returns a sessionid. That sessionid is the token you must attach to every subsequent request — no other endpoint accepts admin credentials directly.

Sessions expire after a period of inactivity. To keep a long-lived client alive, call refreshsessionid periodically (a common pattern is every few minutes while the app is idle). This resets the idle timer without forcing a new login.

When a session has already expired, the next call will return a non-zero errorcode indicating an authentication failure. Your client must detect that code, discard the stale sessionid, and call login again to obtain a fresh one before retrying the original request.

1. Login — obtain a sessionid
POST 
https://www.parlacom.net/cgi-bin/parla
 HTTP/1.1
Host: www.parlacom.net
Content-Type: application/x-www-form-urlencoded
 
function=login&company=parla&admin=alice&adminpwd=•••
Response — capture <sessionid>
<?xml version="1.0" encoding="UTF-8"?>
<login>
  <response>
    <sessionid>1234567890abcdef</sessionid>
    <errorcode>0</errorcode>
  </response>
</login>
2. Use the sessionid on every subsequent call
https://www.parlacom.net/cgi-bin/parla?function=getpinbalance&company=parla&sessionid=1234567890abcdef&pin=8613912345678
3. Keep alive — refresh before idle timeout
https://www.parlacom.net/cgi-bin/parla?function=refreshsessionid&company=parla&sessionid=1234567890abcdef

Rule of thumb: login once, refresh often, re-login on error. Treat the sessionid as a bearer token — store it server-side, never expose it in client bundles, and rotate it whenever the API signals an auth error.

Base URL

base url
https://www.parlacom.net/cgi-bin/parla

Every call selects an endpoint through the function parameter, and works with either GET (query string) or POST (form-urlencoded).

Pro tip

Reverse-engineer any call from the MVNO web app

The Parlacom MVNO web application is itself powered by these same Mercurius endpoints — every page you visit and every button you click is a live example of an API call. Use the browser as your Postman:

  • GET calls — read the URL. When you navigate a report, list, or detail page, the address bar already shows a valid GET request: the function parameter plus the filter values. Copy the URL, swap credentials, and you have a working GET call.
  • POST calls — inspect the form. Any page with a form (add user, edit PIN, send SMS…) posts to the same base URL. Open DevTools → Elements and look at <form action> and the name of each <input>/<select>: those input names are the exact POST body keys. Submit the form once with DevTools → Network open and the request payload is the canonical example body.
GET — copied from the address bar
https://www.parlacom.net/cgi-bin/parla?function=getpinbalance&company=parla&sessionid=…&pin=8613912345678
POST — reconstructed from a <form>
POST 
https://www.parlacom.net/cgi-bin/parla
 HTTP/1.1
Host: www.parlacom.net
Content-Type: application/x-www-form-urlencoded
 
function=adduser&company=parla&sessionid=…&login=alice&pwd=•••&email=alice@example.com

Rule of thumb: URL parameters ⇒ GET template, form fields ⇒ POST body keys. Everything the MVNO UI can do, you can do from your own client with the same parameters.

Authentication

Call login → receive sessionid. Pass sessionid on later calls, or fall back to admin + adminpwd on every request.

Output format

output_type=json returns XML (renamed json), output_type=html returns the same view the web UI renders.

Errors

Every response includes <errorcode>. 0 = success; any other value indicates a failure — see the error code list.

Sessions

sessionid stays valid while the app timeout has not elapsed. If it expires the next call returns an error and you must login again.

Pagination

List endpoints accept limit (default 100, max 500) and offset, or an opaque cursor. Responses include a <pagination> block with total, has_more, and next_cursor.

Pagination

Every list endpoint accepts limit and offset, or an opaque cursor. Cursor paging is preferred for large or frequently changing datasets because it is stable against inserts. Continue paging while has_more is 1.

Request — first page
https://www.parlacom.net/cgi-bin/parla?function=getpincdr
    &pin=1000001
    &startdate=2026-01-01
    &enddate=2026-01-31
    &limit=50
    &offset=0
Response — paginated
<?xml version="1.0" encoding="UTF-8"?>
<response>
  <errorcode>0</errorcode>
  <calls>
    <call><start>2026-01-30T09:12:44Z</start><duration>128</duration><cost>0.42</cost></call>
    <!-- 49 more … -->
  </calls>
  <pagination>
    <limit>50</limit>
    <offset>0</offset>
    <returned>50</returned>
    <total>184</total>
    <has_more>1</has_more>
    <next_cursor>eyJvZmZzZXQiOjUwfQ==</next_cursor>
  </pagination>
</response>
Request — next page (cursor)
https://www.parlacom.net/cgi-bin/parla?function=getpincdr&pin=1000001&limit=50&cursor=eyJvZmZzZXQiOjUwfQ==

Quick start

Request (GET)
GET https://www.parlacom.net/cgi-bin/parla?function=login
    &company=parla
    &output_type=json
    &user=clovis1234
    &password=s3cret
Response (XML)
<?xml version="1.0" encoding="UTF-8"?>
<response>
  <errorcode>0</errorcode>
  <sessionid>617310111715966...</sessionid>
  <expires>3600</expires>
</response>

All endpoints

User Functions & Bank

Virtual PBX & Call Center

PIN — VoIP (ServiceID = 2)

PIN Lists & Status

PIN — M2M (ServiceID = 20)

Mobile, GPS & UPC