Access Policy (legacy)
API family for adding and removing email addresses or patterns on a Sign-In access policy.
Legacy API
This page describes the legacy Sign In API. New integrations use the Sign In API with an Organization API key. The same operation there: Access policy email patterns.
Access policies gate email-driven Sign In Modules — Self-Provisioning by Email, Meeting Host, and Conference. The policy decides which email addresses or domain patterns may sign in. This API family lets an integration manage that allow-list programmatically (HR feed, attendee list, visitor-management system).
Email pattern rules
Section titled “Email pattern rules”Three shapes are accepted everywhere emails[] appears:
- Full address —
alice@acme.com - Domain wildcard —
*@acme.com - Subdomain wildcard —
*@*.acme.com
Patterns are normalised server-side. Adding a pattern that another (non-default) policy already holds produces a warning, not an error — the duplicate is reported and skipped rather than failing the request.
Prerequisites
Section titled “Prerequisites”- The target Sign-In Context has the access policy you’re editing, and at least one email-driven module bound to it.
- Your integration has the Context API key and an approved source IP.
See Legacy Sign In API for the common auth, base URL, and status-code model.
Error body
Section titled “Error body”A failed request in this family returns:
{ "status": 400, "message": "emails must not be empty", "request_id": "6f5e4d3c-..."}status— the HTTP status code, repeated in the body for easy logging.message— human-readable description of what went wrong.request_id— correlation ID; include it when reporting an issue.