CAPI is a control-plane API and service backend for managing user accounts, plan metadata, attack orchestration, Discord verification, and operational monitoring. It is designed to sit behind a lightweight request router and expose a clean JSON API for both public consumers and privileged admin flows.
This project is tailored for a service that needs:
- user authentication and plan verification
- Discord account linking and verification
- attack launch and ongoing status tracking
- admin control of users, methods, and plan policy
- rate limiting, maintenance mode, and operational monitoring
In short: it is the API layer that powers the live service experience and exposes the runtime data needed by bots, dashboards, and admin tooling.
CAPI is not just a static docs repo or a mock server. It is a working API that can:
- validate users and manage access to protected endpoints
- inspect and return user plan information such as plan type, cooldowns, limits, expiry, access flags, and ranking
- expose public operational stats like current attack load and system health
- support Discord-based verification and account linking flows
- manage attack lifecycle data and method metadata
- provide admin tools for users, plans, warnings, logs, and maintenance
- serve lookup endpoints for IP/domain/FiveM/Minecraft metadata
The runtime is structured around a request router in src/orchestrator.js, with the API logic split into route handlers in src/api.js, src/admin.js, and src/lookup.js.
This service exists to centralize all operational logic behind one public API contract instead of spreading logic across multiple disconnected scripts. By doing so, it gives the project these advantages:
- a single response contract across endpoints
- consistent auth and rate-limiting behavior
- easier bot integration via Discord or bearer-token authentication
- cleaner admin controls and user policy handling
- predictable monitoring and error reporting
HTTP request
↓
src/orchestrator.js
↓
/api/* -> src/api.js
/admin/* -> src/admin.js
/lookup/* -> src/lookup.js
↓
shared helpers / DB / settings / policy layers
↓
JSON response + metadata + logging
src/orchestrator.js— top-level request router and route dispatchsrc/api.js— public API endpoints and user-facing flowssrc/admin.js— admin-only management and verification flowssrc/lookup.js— lookup and metadata enrichment endpointssrc/response.js— shared JSON formatting and error constructionsrc/vault-db.js— database access and persisted user/method/plan statesrc/helpers.js— rate limiting, cache, request validation, cooldowns, auth trackingsrc/config.js— service metadata, default config, ads, messages, hintspayload.js— method payload definitions and public method catalogtest/— regression tests for response shape and API behavior
This project is designed to run as a backend service behind a lightweight server or worker runtime.
-
Cloudflare-style worker environment
- request entrypoint lives at a worker/edge boundary
src/orchestrator.jshandles routing and delegates to handlers
-
Node-based server runtime
- run behind a lightweight HTTP server or reverse proxy
- pass requests into the same request dispatcher
-
Internal/private control-plane deployment
- deploy behind a private domain or internal gateway
- use bearer-token bot auth and user/password flows for trusted automation
- Node.js runtime
- SQLite-backed storage or equivalent database layer used by the Vault layer
- environment variables for service name, bot auth, API config, and DB access
- a request router or custom web entrypoint that passes incoming requests into the orchestrator
cd /var/www/CAPI
npm install
npm test
npm run devGET /Returns service metadata, runtime status, and the list of supported action groups.
Common endpoints include:
/api/network_statistics/api/graph/api/methods/api/discord_profile/api/verify/api/link/api/unlink/api/view_plan/api/view_ongoing/api/my_attacks/api/attack/api/stop
These routes are used for operational checks, plan inspection, auth, Discord claims, and attack tracking.
{
"error": false,
"message": "public methods loaded",
"data": [
{
"id": 1,
"name": "udp",
"description": "UDP flood attack",
"target_type": "ip",
"default_port": 80,
"min_time": 10,
"max_time": 600,
"max_concurrents": 3,
"max_slots": 10
}
],
"timestamp": "2026-08-29T16:13:55.223Z",
"service": "CAPI",
"version": "1.0.0",
"ads": "This spot is open for sponsors."
}Admin routes live under /admin/... and require valid admin-level auth. They cover:
- user creation and editing
- password management
- plan and method editing
- log viewing
- user suspension actions
- maintenance and service settings
Lookup endpoints under /lookup/... are used for:
- IP lookup and enrichment
- domain lookup
- FiveM server info
- Minecraft profile-related metadata
The project follows one consistent JSON contract across most routes:
{
"error": false,
"message": "User plan retrieved successfully.",
"data": {
"username": "alice",
"expiry_date": "Lifetime",
"raw_access": false,
"star_access": true,
"botnet_access": false,
"private_access": false,
"plan_type": "VIP",
"rank": "VIP",
"admin": false,
"vip": true,
"holder": false
},
"timestamp": "2026-08-29T16:13:55.223Z",
"service": "CAPI",
"version": "1.0.0",
"ads": "This spot is open for sponsors."
}The API keeps a strict order for readability and consistency:
errormessagehint(when present)- any custom data fields
- metadata fields such as
timestamp,service,version,ads
This means the client can reliably parse JSON without dealing with mislabeled nested wrappers or noisy extra auth counters.
attemptsandlimitare intentionally omitted from auth failures in the final response payload- nested wrappers such as
data.profileare flattened when they are redundant view_planandview_user_planuse a flatdataobject;plan_typeandrankare the final fields- plan responses use
expiry_dateand access flags such asraw_access,star_access,botnet_access, andprivate_access plan_id,expiry_unix,formatted_expiry, and plan-levelservice_nameare not returned
The API supports multiple auth patterns depending on the route:
?username=alice&password=secret123
Authorization: Bearer <BOT_API_KEY>
Some flows allow a bot or trusted client to act on behalf of a verified Discord-linked user, providing a smoother integration path for chat or automation tools.
curl "https://your-capi-host/"curl "https://your-capi-host/api/view_plan?username=alice&password=secret123"curl "https://your-capi-host/api/network_statistics"curl "https://your-capi-host/api/verify?username=alice&password=secret123&client=discord"- All response helpers are centralized for consistent payload ordering and metadata injection.
- The system keeps rate limiting and cooldown logic in the shared helpers so routes behave similarly.
- The codebase was written to keep the API contract stable for both frontend and Discord bot consumers.
- For live API examples, see API_ENDPOINTS.md and API_RESPONSE.md.
This repository is intended for internal/project use and is not a public package release unless explicitly stated otherwise.