Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/thenoname-gurl/EcliPanel/llms.txt

Use this file to discover all available pages before exploring further.

EcliPanel includes a billing system that ties portal tier upgrades to orders. Plans define the resource limits and portal tier a user receives, orders record the purchase intent, and PDF invoices are generated server-side for each completed order. The entire billing subsystem is gated behind the billing feature flag — if your deployment does not need paid plans, you can disable it without affecting any other part of the panel.
Billing is optional. Set the billing feature flag to false in your panel settings to hide billing UI and disable billing endpoints for all users.

​
Plans

A Plan represents a purchasable tier with specific resource allocations. Each plan has the following fields from the Plan entity:
FieldTypeDescription
namestringDisplay name shown in the billing UI
typestringPortal tier this plan grants (free, paid, etc.)
pricefloatPrice in your configured currency
memorynumberRAM allocation in MB
disknumberDisk allocation in MB
cpunumberCPU allocation (percentage)
serverLimitnumberMaximum number of servers
databasesnumberNumber of databases per server
backupsnumberNumber of backups per server
portCountnumberNumber of network port allocations per server
tunnelPortCountnumberNumber of tunnel allocations included in the plan
hiddenFromBillingbooleanHides the plan from the user-facing billing page
Plans can also carry an arbitrary features JSON object for custom feature flags.

​
Listing and managing plans

GET  /api/plans              # list all public plans
GET  /api/plans/:id          # plan detail
GET  /api/admin/plans        # admin: list all plans including hidden
POST /api/admin/plans        # admin: create a plan
PUT  /api/admin/plans/:id    # admin: update a plan
To reapply a plan’s limits to all users currently on that plan (for example after updating resource values): 
POST /api/admin/plans/:id/reapply-limits

​
Placing orders

Users place an order to request a plan upgrade. The order is recorded and an admin can then approve it by applying the plan: 
GET  /api/orders             # list my orders
POST /api/orders             # create a new order
GET  /api/orders/:id         # order detail

​
Viewing invoices

Each order has a downloadable PDF invoice generated server-side using pdfkit. The PDF includes:
  • Company logo (configured via INVOICE_LOGO_PATH environment variable)
  • Issuer details (COMPANY_NAME, INVOICE_ISSUED_FROM_NAME, address, city, email)
  • Invoice number, date, and bill-to details for the purchasing user
GET /api/orders/:id/invoice
The endpoint streams the rendered PDF directly to the browser as application/pdf.
PDF generation uses a dedicated worker (pdfWorker) to avoid blocking the main Elysia event loop. If the worker fails, the handler falls back to an inline PDFDocument render.

​
Admin order management

Admins can view and manage all orders across every user: 
GET /api/admin/orders           # list all orders
GET /api/admin/orders/:id       # order detail

​
Applying a plan to a user

The most common admin billing action is manually applying a plan to a user after their payment is confirmed outside the panel (bank transfer, manual approval, etc.): 
POST /api/admin/users/:id/apply-plan

{ "planId": 3 }
To check which plan is currently applied to a user: 
GET /api/admin/users/:id/current-plan
To cancel a user’s active plan: 
POST /api/admin/users/:id/cancel-plan

​
Billing subscription endpoint

If you integrate with an external payment processor (Stripe, etc.) you can wire it to the subscription endpoint: 
POST /api/billing/subscribe
GET  /api/billing/invoices
These endpoints exist as hooks for custom billing integrations. The panel does not include a default payment processor — connect your own via environment-level configuration.

Build docs developers (and LLMs) love

Get started for freeTalk to us