Authentication

Authentication patterns for tenant sessions, tenant-admin API keys, and webhook verification in the customer-facing VexylCloud API.

API authentication

Current public API access is built around authenticated tenant sessions, with tenant API keys available for admin automation.

The buyer question here is simple: how does an external script, CLI tool, or integration authenticate safely? In the current build, the broader tenant-aware REST surface follows authenticated VexylCloud sessions, while tenant API keys are available from the admin layer for control-plane automation such as API-key and webhook management.

Authenticated tenant sessions

Most customer-facing REST routes inherit tenant context from the authenticated operator session, role, and RBAC permissions.

Tenant API keys

Tenant-admin API keys are generated through /api/admin/api-keys. The plaintext key is returned once, only the hash is stored, and the current control-plane use case is admin automation around keys and webhooks.

Webhook verification

Outbound webhook deliveries are signed so external receivers can validate that the event really came from VexylCloud.

Practical start

1. Sign in to VexylCloud as a tenant admin
2. Create or review tenant API keys at /api/admin/api-keys
3. Import /api/openapi.json into your client
4. Use your authenticated tenant session for the wider REST surface

Representative patterns

Session-authenticated request
GET /api/admin/webhooks
Cookie: <authenticated VexylCloud tenant session>

Tenant API key
Authorization: Bearer vxc_...

Relevant public routes in the current build

  • /api/admin/api-keys for creating, listing, updating, and revoking tenant API keys
  • /api/admin/webhooks for tenant-admin webhook configuration
  • /api/psa/tickets and /api/psa/workflows/trigger for service-desk automation
  • /api/cloud/providers and /api/cloud/vms for cloud credential and VM workflows
  • /api/backup/config, /api/backup/customer-aggregate, /api/search, and /api/rmm/reports/asset-inventory for configuration, reporting, and search
  • /api/openapi.json for the canonical published OpenAPI spec
What this page is intentionally not about

This page is about the customer-facing API surface used to control and integrate VexylCloud. It intentionally does not lead with internal ingest, cron, or provider-callback authentication because those are not the buyer-facing integration paths most teams need first.

Need auth reviewed against a real integration?

Use a technical walkthrough if you want us to map the auth model to your intended admin, automation, or provider workflow.

Book Demo