Authentication

The code already uses different authentication models for different route classes. Tenant admin integrations use managed API keys, RMM ingest uses agent bearer tokens, webhook endpoints use per-webhook secrets, and scheduled or backend automation flows use their own bearer-token patterns.

Tenant API keys Create tenant-scoped keys with prefixes, scopes, activation flags, expiry windows, and one-time plaintext return on creation.

Agent ingest auth RMM ingest accepts signed bearer tokens for deployed agents and keeps tenant context tied to the authenticated agent record.

Webhook and automation secrets Webhook endpoints and scheduled jobs use their own secrets instead of pretending every request is the same kind of browser login.

Authentication models already represented in the code

Tenant auth

Tenant API keys

The admin API-key surface creates tenant-scoped keys with prefixes, hashed storage, scopes, activation flags, and one-time plaintext return on creation.

Agent auth

Bearer tokens for RMM ingest

RMM agents authenticate with bearer tokens derived from agent identity and signature checks, with a compatibility path for current installer tokens.

Event delivery

Webhook secrets and event scopes

Tenant webhook records include URL, event selections, active status, and generated secrets for outbound delivery workflows.

Key handling Tenant API keys are stored as hashes and only shown in plaintext once That matters for teams evaluating whether the admin API-key surface is operational or just placeholder copy.

The admin API-key route generates a prefixed key, stores only the SHA-256 hash, and returns the plaintext value once at creation time.

Agent ingest Agent authentication supports signed bearer tokens and compatibility tokens The ingest layer accepts bearer or token headers and maps the request back to the tenant and agent record.

Signed agent tokens use an agent_id.signature pattern, while the compatibility path still supports per-agent secret tokens used by current installers.

Control plane Rate limits, scopes, and webhook records sit alongside the auth surfaces Authentication in VexylCloud is tied to practical control-plane behavior, not just a login page.

The code already pairs auth models with scopes, active flags, webhook event choices, and rate-limit headers so integrations can be operated and governed as part of the product.

Review the integration surfaces together.

Use the API, webhooks, and rate-limit pages together if you are evaluating how VexylCloud handles tenant integrations, agent ingest, and outbound events.

Open API Open Webhooks