API reference and authentication

Prerequisites and authority

Use this reference with your installed release. Internal implementation routes and settings are not public integration contracts.

Supported integration API contract

Only supported customer-installation integration endpoints and their authentication belong in the public reference. Internal bot/router callbacks, update control and administrator implementation routes are not automatically stable public integrations.

An interest in third-party integrations is not a stable endpoint contract. Until a versioned integration allowlist is explicitly supplied, this guide describes authentication boundaries and the application's route inventory only. Do not build an external integration against internal callbacks or assume customer-interface endpoints have a compatibility guarantee. Agree the intended workflow and its versioned contract before relying on it in another product.

Authentication and handling rules

Use the supported credentials/token acquisition flow for the selected integration. A customer JWT identifies an application session and is not a RouterOS password or a generated router secret. Keep internal service tokens off customer clients.

Send bearer tokens through the documented authorization mechanism over HTTPS. Never include them in URLs or shared logs. Handle expired/revoked sessions through the supported re-authentication route instead of retrying indefinitely.

For each approved endpoint, publish method/path, request and response schemas, authorization scope, rate limit, pagination, error behavior, idempotency and a redacted example. Rate limits and stability promises must come from actual release evidence, not generic conventions.

An integration must distinguish payment status, subscription state and provisioning outcome. Retries that can change economic/access state require a documented idempotency contract.

Before commissioning an integration, agree the intended workflow, supported API version, authentication scope and compatibility requirements with BryanNet. A route used by the shipped customer website or bot is not automatically a supported third-party integration contract.

Customer authentication boundaries

Use the official customer interface for registration, sign-in, account linking, session management and password recovery. Do not call internal Telegram claim/decision callbacks or copy internal service credentials into an external application. For an approved custom integration, obtain the matching version's endpoint and schema reference rather than inferring a contract from browser traffic.

Related guides

Related guides: Configuration reference (env vars, ports, URLs), Docker services, Compose files and persistent volumes, Database diagnostics and safe query reference, Subscription and provisioning state model.