Provisioning tenants (resellers)

This guide is for resellers / platforms serving many organizations. A single organization embedding meetings in its own app does not need any of this — take the Quickstart path instead.

You hold one provider key (vcp_prov_…, header x-provider-key), a backend-only credential. It provisions and manages tenants; it never joins meetings.

Provision a tenant per customer

POST /api/v1/provider/tenants
x-provider-key: vcp_prov_…
Content-Type: application/json

{
  "name": "Acme Clinic",
  "slug": "acme-clinic",
  "plan": "PRO",
  "webhookUrl": "https://your-backend.example.com/webhooks/etite/acme-clinic",
  "isTestMode": false
}

The response returns the new tenant plus its API key and webhook secret, shown once — store them encrypted:

{
  "tenant": { "id": "clh…", "slug": "acme-clinic", "plan": "PRO" },
  "apiKey": "vcp_live_…",
  "webhookSecret": "whsec_…"
}

From then on you act on that customer's behalf with their tenant key — every call in the Quickstart works the same way.

Managing owned tenants

• List and inspect: GET /provider/tenants, GET /provider/tenants/{id}
• Update: PATCH /provider/tenants/{id}
• Rotate a tenant's API key: POST /provider/tenants/{id}/api-keys/{keyId}/rotate
• Rotate a tenant's webhook secret: POST /provider/tenants/{id}/webhook-secret/rotate
• Usage across your fleet: GET /provider/usage

See the Provider endpoints in the API reference for the full surface.