Unsupported XC actions

Two families of classic XC / XUI.one actions are deliberately not implemented. Every unsupported action returns HTTP 200 with a STATUS_FAILURE envelope so classic clients that branch on the status field see a clean failure rather than a hard HTTP error. The error slug and message tell the integrator exactly why.

Arbitrary SQL execution: `action=mysql_query`

The classic panels expose action=mysql_query, which runs arbitrary SQL against the panel database over HTTP. Xtream AI refuses it.

Response.

{
  "status": "STATUS_FAILURE",
  "data": {
    "error": "forbidden_action",
    "message": "Arbitrary SQL execution is intentionally not exposed by this API."
  }
}

Why. Arbitrary SQL over HTTP is the root of most of the well-known Xtream Codes and XUI.one incidents (data exfiltration, credential theft, privilege escalation, ransomware pivoting). There is no scope, no rate limit, no idempotency semantics, and no audit trail that can make an "execute any query" endpoint safe. We do not implement it in any dialect and we will not implement it in the future.

What to do instead. If your integration depends on mysql_query for something the first-class API does not cover (a report, a niche filter, a bulk fix-up), contact us and describe the use case. New first-class endpoints are prioritized exactly by these gaps.

MAG device management

The classic panels expose actions to enrol and manage physical MAG STB devices. Xtream AI does not provision MAG devices; the product concept in Xtream AI is a subscriber Line with the appropriate flags on the client device.

Actions rejected.

get_mag
get_mags
create_mag
edit_mag
delete_mag
enable_mag
disable_mag
ban_mag
unban_mag
convert_mag

Response. Every one of the actions above returns the same body.

{
  "status": "STATUS_FAILURE",
  "data": {
    "error": "not_implemented",
    "message": "This product has no MAG/Enigma device management. Use Lines with the appropriate flags on the client device instead."
  }
}

What to do instead. Provision a regular Line (action=create_line) and configure the MAG device on the client side to use the Line's username and password.

Enigma device management

Same as MAG. Enigma (Enigma2, Dreambox and compatible receivers) is not provisioned server-side by Xtream AI.

Actions rejected.

get_enigma
get_enigmas
create_enigma
edit_enigma
delete_enigma
enable_enigma
disable_enigma
ban_enigma
unban_enigma
convert_enigma

Response. Identical to the MAG family.

{
  "status": "STATUS_FAILURE",
  "data": {
    "error": "not_implemented",
    "message": "This product has no MAG/Enigma device management. Use Lines with the appropriate flags on the client device instead."
  }
}

What to do instead. Provision a regular Line and configure the Enigma receiver on the client side to use the Line's username and password.

Path variations for device management

Some legacy integrations hardcode /mag/index.php or /enigma/index.php in the base URL rather than passing action=create_mag (etc.) against /admin/index.php. Under /panel-api/xc/, the routing layer accepts those path variants so old code does not 404 at the network layer. Every action reached that way still returns not_implemented with the message above.

Unknown or misspelled actions

Any action name that is not in the supported list and not in the two rejected families above returns STATUS_FAILURE with error: "not_implemented" and a message quoting the action name.

Example.

{
  "status": "STATUS_FAILURE",
  "data": {
    "error": "not_implemented",
    "message": "Action 'nonsense_action' is not supported."
  }
}

If you get this on an action name your classic panel accepted, check the full mapping table to confirm the exact spelling used by the XC compatibility dialect. If it truly does not exist in the classic contract and your integration needs it, contact us.

Global connection listing and global connection kill

The classic panels expose "list every active connection across every line" and "kill every active connection" endpoints. Xtream AI intentionally does not.

Per-line connection inspection is available through the native GET /panel-api/v1/lines/{id}/connections endpoint. See Panel API Lines.
Global kill is not exposed by design. Blast-radius on a shared panel is too large to gate behind a single API key.

If you need a workflow that the classic global endpoints supported (mass-eviction of a specific package, scheduled disconnect windows, etc.), reach out and we can scope a first-class endpoint with proper controls (scope, audit, idempotency).

Bulk fields the native line update does not accept

The classic edit_line accepted several fields that the native POST /lines/{id}/update handler does not:

bouquets_selected[]
username
notes
is_trial

If you call edit_line with only unsupported fields, the compat layer returns STATUS_INVALID_DATA with an explicit message listing the fields that ARE supported. If you call edit_line with a mix of supported and unsupported fields, the supported ones are applied and the unsupported ones are silently dropped with STATUS_SUCCESS.

Recommendation: pass only fields the native update handler accepts (password, exp_date, max_connections, is_restreamer, enabled, admin_enabled, allowed_ips, allowed_ua). If you need to change bouquets, the current workaround is deletion plus recreation. See the edit_line footgun note for background.