Access and automation

The platform has three separate credential domains. Keep them separate in storage, logging, and incident response.

Credential	Used for	Never send it to
Operator session and 2FA	Vue 3 admin access	Customer code or proxy gateway ports
JWT or static API key	Public control-plane API	A proxy username, browser bundle, or customer-visible log
Proxy username and password	HTTP/SOCKS gateway authentication	The REST API Authorization header

API keys

Open full size

Create separate keys for production, staging, and bounded operational integrations.

1. 1The page controls start key creation and help operators find the correct owner.
2. 2The table shows title, user, masked key, allowed IPs, and creation time without exposing the secret.

Use a static API key only from a trusted backend. Give each application and environment its own key, apply the narrowest source-IP range, and keep it in a secret manager. If a deployment supports scoped capabilities for the key or owner, grant only the operations that integration requires.

Rotation sequence

1. Create a replacement key with the same intended network restrictions.
2. Store it in the deployment secret manager and release one consumer environment.
3. Verify authenticated reads and one safe end-to-end workflow.
4. Roll out the remaining consumers and monitor authentication failures.
5. Revoke the old key and record the change in the audit trail.

The full value may be available only once. Never depend on listing the resource to recover a lost secret.

Webhooks

Open full size

Webhook rows make event scope and destination ownership visible to operators.

1. 1Webhook controls create and find destinations for a specific customer integration.
2. 2The current table shows user, event type, endpoint URL, and creation time.

The webhook create response returns a signing secret. Save it immediately; subsequent list/retrieve responses intentionally do not reveal it. Verify X-Signature against the exact raw request bytes with Base64-encoded HMAC-SHA256 before parsing or enqueueing the body.

Fast receiver

Verify, validate, persist or enqueue, and return a direct 2xx. Do not run customer billing logic inside the delivery request.

Idempotent consumer

Retries and coalesced batches are expected. Reprocessing the same balance must not grant data or charge money twice.

Independent reconciliation

Webhooks update a projection quickly. Closed analytics windows and durable order/ledger state repair missed or ambiguous delivery.

Operator access

Create named operator accounts instead of sharing one administrator login. Require 2FA for privileged users, separate support/billing/supply/infrastructure duties where practical, and review active sessions after staff or vendor changes.

The audit log should answer who changed a package, provider, pool, customer balance, key, webhook, or setting; what changed; when; and from which request context. Request IDs and user IDs belong in server logs for incident correlation, but customer-facing tables should show business labels where possible.

Do not paste secrets into support evidence

Redact API keys, provider credentials, proxy passwords, webhook secrets, session tokens, and authorization headers before sharing logs or screenshots.

Automation safety pattern

1. Generate an internal operation ID before a write.
2. Persist local-to-platform user, package, order, invoice, and ledger mappings immediately after success.
3. Apply timeouts and bounded retries only to safe reads.
4. After an ambiguous write, read the resource state before repeating it.
5. Record the exact byte and money units used by the request.
6. Correlate webhook deliveries, API request IDs, audit entries, and analytics windows.

For API headers and schemas, use API fundamentals and the generated API Reference.