The Panel API is the same panel you already use from the browser, exposed as a set of HTTP endpoints your own software can call. It lets a billing system, a Telegram bot, a website, or a nightly script perform the operations you would otherwise perform by hand: creating lines for a new customer, renewing subscriptions on payment, disabling users who did not pay, moving credits between resellers, or reading the current catalog of packages and channels.
The audience for this API is anyone who runs workflows around the panel and does not want a human to be part of every step. If you sell your service through a website that already handles checkout, the Panel API is what closes the loop between "the customer paid" and "the line is live". If you manage a network of resellers, it is what lets your back office push credits and enforce quotas from one place instead of clicking through the panel one account at a time.
The difference from the panel UI is not what you can do. It is how you talk to it. The UI is designed for a person in front of a screen. The API is designed for another program. Every action returns a machine readable answer, every write can be safely repeated if your network drops in the middle of a request, and the same API key can serve your web app, your billing integration, and a one off migration script without any extra setup on your side.
What you can automate
Anything that involves a customer line, a reseller account, or the catalog can be automated end to end. The list below is the short version of what most integrators wire up first.
- Create customer lines the moment payment clears. Your checkout page or your billing platform calls one endpoint and the credentials are ready before the "thank you" screen finishes loading.
- Renew subscriptions on schedule. A monthly cron or a payment webhook extends the expiration date on the customer's line without a human touching the panel.
- Suspend or disable non paying customers. Your dunning process disables the line and re enables it the moment the invoice is paid.
- Move reseller credits. Top ups, refunds, and internal transfers happen from your billing tool with a full audit trail on both sides.
- Read the catalog. Packages, bouquets, channels, and movies can be pulled to feed your public storefront, your mobile app, or your customer support tooling.
- Run bulk migrations. A one off script can create thousands of lines from a spreadsheet in a single afternoon, with the panel enforcing every business rule you already trust.
What a typical integration looks like
Most integrations follow one of three shapes. Recognizing which one you are building will make the rest of this documentation easier to navigate, because the pages you visit next depend on the shape you pick.
A billing hook
The customer finishes payment on your website or on a third party billing platform. The moment the payment webhook fires, your code calls the Panel API to create the line and receives back the username, the password, and the M3U URL. Your confirmation page or your welcome email delivers those credentials to the customer. The whole round trip takes less than a second and the customer never notices there was a panel in the middle.
A scheduled job
A cron on your server runs on a regular interval, usually once an hour or once a day. It queries your own database for lines that are about to expire, calls the Panel API to renew the ones that were paid, and disables the ones that were not. This shape is popular because it keeps every payment decision inside your own systems and treats the panel as a downstream service that only needs to know the final outcome.
A reseller back office
Your resellers log into your own dashboard, not into the panel directly. When a reseller tops up a balance or creates a subscription for one of their customers, your dashboard calls the Panel API on their behalf using an admin scoped key. This shape lets you brand the whole experience, keep pricing rules on your side, and never expose the panel UI to the resellers themselves.
Choose your path
The Panel API has two audiences and two on ramps. Pick the one that matches where your code is today.
You already have code that talks to Xtream Codes, XUI.one, or OneStream
Your existing calls keep working here. Actions like create_line, edit_line, and enable_line are recognized on the compatible endpoints, and the response shapes match what your code already parses. In most cases the change is one base URL and one API key. A small number of legacy actions do not have an equivalent on this panel. The compatibility page lists them one by one with the recommended replacement, so you can plan the migration before you touch a single file.
Start with the compatibility page if migration is your goal. It walks through the exact URL you point your code at, the header you add, and the handful of edge cases that behave differently from the panel you are leaving behind.
Migrating from Xtream Codes, XUI.one, or OneStream
You are starting from zero
If there is no existing code to preserve, use the official SDK for PHP or Python. The Quickstart walks through creating an API key from the panel UI, installing the SDK, and making your first working call in about five minutes. From there the SDK gives you typed models for every resource and takes care of the small operational details you would otherwise have to write and maintain yourself.
Quickstart, first working call in five minutes
The three ways to talk to the API
There are three flavors of the API and they exist for one reason: to fit the code you already have. A brand new project will use the native flavor with an SDK. A project that grew up on Xtream Codes or OneStream can point at the matching compatible flavor and keep most of its integration logic intact. All three flavors are served by the same panel and backed by the same data.
| Flavor | Base URL | Best for |
|---|---|---|
| Native v1 with official SDKs | https://<your-panel-domain>/panel-api/v1/* |
New projects built from zero |
| Xtream Codes compatible | https://<your-panel-domain>/panel-api/xc/{accesscode}/{admin\|reseller}/index.php |
Code originally written for Xtream Codes or XUI.one |
| OneStream compatible | https://<your-panel-domain>/panel-api/onestream/ext/* |
Code originally written for OneStream |
The same API key works across all three flavors. You do not need one credential for the native endpoints and another for the compatible ones. Pick the flavor that matches your code, use your key as a Bearer token, and every endpoint is unlocked.
In the Xtream Codes URL the
{accesscode}segment can be any word you like. The API key is what protects the panel, not the path.
Your first request
Every panel answers a public health check that requires no authentication. Run it from the same server your integration will run on. It proves that your server can reach the panel over the network before you even think about credentials or payloads.
curl https://<your-panel-domain>/panel-api/v1/healthYou should see this response:
{"status":"ok","version":"v1"}The /health endpoint is the only one on the API that does not require an API key. It is intentionally boring. Its whole job is to tell you the panel is up and the API layer is enabled. If this call succeeds from your integration server, everything else is a matter of adding the right header. If it fails, the problem is network or DNS, not the API, and it is worth solving there before you start debugging keys or request bodies.
What the API sends back
Every response is JSON. Successful requests return the object you asked for or a list of objects, depending on the endpoint. Failing requests return a short error slug and a human readable message, so you can log the slug for alerting and show the message to the person who triggered the request. HTTP status codes follow the usual conventions, with 2xx for success, 4xx for problems on the client side, and 5xx for problems on the panel side. The reference pages show a full example response for every endpoint you are likely to call.
What is out of scope
The Panel API covers operations. It does not cover video ingestion, transcoding, or delivery. Those live at the media layer of the streaming engine and are managed from the panel UI or through the engine's own tooling. If your goal is to build automation around customer lifecycle, billing, catalog management, or resellers, you are in the right place. If your goal is to inject a new live signal into the panel or to change how a channel is transcoded, that work happens through a different interface and is documented separately.
How authentication works, in one paragraph
The Panel API is protected by an API key that you create yourself from the panel UI. You send that key as a Bearer token in the Authorization header on every request, and the panel decides what your key is allowed to do based on the scopes you granted when you created it. The Quickstart shows the exact clicks to generate a key. The Authentication page covers scopes, rotation, and the finer points of managing keys across environments.
Where to go next
- Quickstart. Your first working call, step by step.
- Common Tasks. Copy paste code for the jobs every integrator does first.
- SDKs. Install the official PHP or Python library.
- Authentication. How to create and manage your API key.