Legacy Sign In API
Programmatic access to a Sign-In Context: Username & Password users, Access Policy emails, and Whitelisting.
Legacy API
This page describes the legacy Sign In API for the Sign-In Contexts that use it today. It cannot be turned on for another context. New integrations use the Platform API with an API key: see Introduction. Operation and field mapping: Migrate from the legacy API.
The Sign-In public API lets integrations manage three things inside a Sign-In Context without driving the admin UI:
- Username & Password — user accounts provisioned and rotated by the integration (HR system, PMS, event system).
- Access Policy — add or remove email patterns that gate self-provisioning and Meeting Host modules.
- Whitelisting — allow-list devices by MAC address so they bypass the Captive Portal.
The API is a thin management surface — it does not expose sign-in logs, guest sessions, or admin-only configuration. Use Webhooks to observe sign-in activity.
Authentication
Section titled “Authentication”Every request carries a per-Context API key in the x-auth-token
header. The key lives on the Context: in the Sign-In Context admin,
open Administration → Configuration → Common Settings and find
the Legacy API access card, which a Context that uses the legacy
API has. Change the key under Legacy API key, or turn the API off
with Legacy API access; it cannot be turned on again. The card
lists every endpoint of the legacy API.
| Parameter | In | Type | Required | Description |
|---|---|---|---|---|
x-auth-token | Header | string | Yes | API key for the target Sign-In Context. Rotatable from the admin. |
The caller’s source IP must also be listed in the Organization’s
Admin Dashboard Access list in Organization Settings. Calls from
IPs outside the list return 403 Forbidden regardless of the API key. Coordinate
whitelisting with the Organization admin before integration goes
live.
Base URL
Section titled “Base URL”Every endpoint is built the same way:
{apiHost}/v1/org/{organizationId}/contexts/sign-in/{contextId}/...The path is fixed across every deployment. The host is not — different Organizations may have different hostnames depending on how the platform was provisioned. There is no single default to assume.
Finding your {apiHost}
Section titled “Finding your {apiHost}”To find the value that applies to your Organization:
- Check the dashboard instructions on your Organization’s admin home page — they list the API base URL that’s been configured for your deployment.
- If the dashboard doesn’t show it, ask your Organization admin for the integration base URL.
Use that value wherever these docs show {apiHost} or $API_HOST
in examples. It is the API base URL on the Organization’s
Applications page without /api/v2 at the end: the
legacy paths start right after the host.
Path parameters
Section titled “Path parameters”| Parameter | In | Type | Required | Description |
|---|---|---|---|---|
organizationId | Path | string | Yes | Organization ID the Sign-In Context belongs to. Visible alongside the base URL in the dashboard instructions. |
contextId | Path | string | Yes | Sign-In Context ID. Visible alongside the base URL in the dashboard instructions. |
Content type
Section titled “Content type”All request and response bodies are JSON. Set:
Content-Type: application/jsonAccept: application/jsonHTTP status codes
Section titled “HTTP status codes”Common across every endpoint:
| Status | Meaning |
|---|---|
200 | Success. |
204 | Success, no response body (DELETE). |
400 | Request body failed validation. Body shape is family-specific — see the per-family overview. |
401 | Missing or invalid x-auth-token. |
403 | Source IP is not whitelisted, or the Context / Organization cannot be resolved. |
The error body shape depends on which API family you called. Each family’s overview page documents its exact shape alongside its validation rules and prerequisites.