API Overview and Conventions

This category is derived from the requests made by the new RustMinerSystem frontend. It covers mining-proxy administration, Observer mode, fleet control, WebSocket traffic, and the embedded PoolNode administration endpoints.

Current availability

The external API is designed to require no UI login: every request will carry a dedicated custom authentication header. That feature is not complete, so:

• External API clients do not call the management-login endpoints or obtain a backend login token.
• Login endpoints are retained only as an inventory of internal frontend calls, not as an API prerequisite.
• Once custom API headers are implemented, key creation, scopes, revocation, expiry, source restrictions, and rate limits must be documented.
• Fields and response formats remain dependent on the running backend version.

Base URL

The base URL is the RustMinerSystem backend address, including its safe route:

https://host:web-port/{safe-route}/api/...

For a backend at https://miner.example.com/rms-admin/, the port-list endpoint is:

https://miner.example.com/rms-admin/api/ports

Without a safe route, the API is under the website root. A reverse proxy must preserve the safe route and custom API header.

API authentication header

API calls require no login. Once implemented, each request will send:

<custom header name>: <API credential>
Content-Type: application/json

The official header name and credential format will be added when the backend feature is complete. Third-party clients must not substitute the management UI’s Authorization: Bearer <login token>.

Observer read-only requests use a separate credential:

X-OB-TOKEN: <Observer token>

The bundled frontend interceptor also writes a non-standard header named ContentType. That is an internal UI detail; third-party callers should send the standard Content-Type header.

Responses and errors

Mining-proxy endpoints commonly return an object, array, string, or number directly in the HTTP body. Some PoolNode administration endpoints use an envelope:

{
  "status": 0,
  "error": null,
  "data": {}
}

The frontend handles these states explicitly:

An error may be reported through message, error, or a business status. Do not treat every HTTP 200 response as business success.

Covered modules

The new frontend defines 146 API identifiers and references 140 of them. The documentation is organized into:

• API headers, permissions, and the boundary around internal UI sessions.
• Dashboard, versions, and system configuration.
• Proxy ports and fee wallets.
• Workers, wallet statistics, charts, and logs.
• Web security, certificates, firewalls, and runtime logs.
• Observer read-only queries.
• Fleet-control forwarding.
• PoolNode project, website, revenue, and subaccount administration.
• Real-time WebSocket data and error handling.

Security guidance

• Expose the API only through HTTPS.
• Never place API, Observer, or fleet-control credentials in URLs, logs, or screenshots.
• Back up configuration before changing ports, wallets, allowlists, certificates, or safe routes.
• Automation should enforce connect, read, and total timeouts and use bounded retry backoff.
• Until custom API headers are available, exposing these internal administration endpoints directly to the public Internet is not recommended.