API reference

Every method behind Voiplix's /api/<method> endpoint, one page per group: what it does, who may call it, its parameters, the hash order and an example call and response.

This reference assumes the API is already switched on. If you haven't done that yet, or don't know what the hash signature is, start with The API — it covers enabling the API, the API Secret Key, how the hash signature is built, and two working curl examples. This reference does not repeat any of that; it only adds the method-by-method detail.

How to read a method page

Every method on the following pages is listed the same way:

Field	Meaning
Name	The method name — call it as `/api/<name>`. A few methods are also reachable under an older route name; that's noted where it applies.
What it does	One line, in plain words.
Who may call it	Which account type(s) the call is meant for. Calls are signed with the installation's API Secret Key (see The API): keep that key secret and switch the API on only when you use it — whoever holds the key can make calls for any account.
Parameters	Required and optional fields, taken directly from the handler code.
Hash parameter order	The exact order values are concatenated in before the secret key is appended and hashed. Only parameters you actually send are included — skip the ones you don't use. A handful of methods define their own order (it's given on their page); every other method falls back to one long shared order that never includes `u` itself. In practice that means a plain call that only sends `u` and nothing else from that shared list hashes to `SHA1(secret key)` alone — unintuitive, but exact.
Example	A `curl` call with placeholder host, user and hash, and the shape of a successful response (field names only — never real data).

The quickest way to get a real hash for testing is the Hash generator on The API's settings page: enter a method name and its parameters (one key=value per line) and it signs them with the secret key already saved there.

Hash generator filled in with method active_calls_get and parameter u=admin, showing a generated SHA1 hash below the Generate Hash button. — The hash generator, worked through for `active_calls_get` with `u=admin` — matching the fixed hash order given on its page.

Response format

Almost every method answers with an XML document — <?xml version="1.0" encoding="UTF-8"?> followed by a <page> element (content type text/xml or text/html, depending on the installation's Response as text/xml setting; the body is identical either way). Three balance-lookup methods on the Users & balance page are the exception: user_simple_balance_get, user_balance_get_by_psw and user_balance_get_by_username return a plain number as text/plain, with no XML wrapper and no hash check at all — they're built for a phone display or a simple script, not a full client. One more method bends the <page> rule on success only: invoices_get (on the billing page) returns <Invoices>/<Invoice> as its document root instead — its own error responses still use <page> like everything else.

Error format

A rejected or failed call is still HTTP 200 — the API never uses an HTTP error status to signal a problem. Read the body instead: it comes back as <status><error>...</error></status> (nested inside <page> for most methods). Some of the older methods put a bare <error> straight under <page> instead of inside a <status> block — the per-method pages say which shape applies.

Most error text is a plain English sentence — User was not found, Bad login, Device was not found. A handful of methods, though, answer with an internal placeholder string that was never translated into a sentence — Dont_be_so_smart (used when a call tries something it plainly shouldn't, e.g. referencing an object outside the caller's own account) and Feature_Disabled (a method that depends on a switch the installation hasn't turned on) are the two you'll meet most. Treat these as fixed literal strings to match against, not as text to show a user.

Note

The four gate errors from The API — API Requests are disabled, GET Requests are disabled, API must have Secret Key, Incorrect hash — apply before any method-specific check runs. A method you call while the API is off will always answer with the first of those, never with its own error text. Calling a method name that doesn't exist answers Unknown method.

Method groups

Not available through the API yet

These method names are recognized by the API but are not wired up yet. Calling them doesn't fail silently — you get back an honest <error> saying so, not "Unknown method":

Method	What it answers
`user_register`	User registration not yet exposed via API
`payment_create`	Payment create requires a payment gateway (not yet wired)
`voucher_use`	Voucher redemption not yet exposed via API
`invoice_xlsx_generate`	Invoice XLSX generation not yet exposed via API
`tariff_retail_import` / `tariff_wholesale_update`	Retail tariff import / wholesale tariff update not yet exposed via API
Calling-card methods (`card_from_group_sell`, `card_by_cli_update`, `card_group_get`) and `cli_info_get`	Not yet exposed via API
`user_details_update`	User detail update not yet exposed via API
`monitoring_addon_activate`	Monitoring addon not exposed via API