Vanity Pages Implementation
This guide shows a full working pattern for embedding Wacht API Auth pages inside your SaaS settings UI.What users will get
- They open your
API Keyssettings page. - Your app fetches a short-lived access ticket from your backend.
- Your app renders Wacht API Auth in an iframe.
- They can create, rotate, and revoke keys without leaving your product.
Step 0: create your API Auth app (one-time provisioning)
Before embedding, create an API Auth app for each tenant/deployment.app_slugnamekey_prefix
aa_<deploymentId>.
Full backend example (Express)
Create an endpoint in your backend that validates permissions, then issues a ticket.Full frontend example (React)
Create a full page component that fetches a ticket and embeds the vanity UI.Route wiring example (React Router)
Security requirements
- Issue tickets only from backend.
- Enforce RBAC before ticket creation.
- Keep expiry short (for example 120 seconds).
- Validate tenant ownership before using
aa_<deploymentId>.
Where backend_host comes from
In the real console flow, iframe base URL is derived from the deployment context:
SDK + API references
- React Router
useApiAuthAppSession - React Router
useApiAuthKeys - React Router
useApiAuthAuditLogs - React Router
useApiAuthAuditAnalytics - React Router
useApiAuthAuditTimeseries - API Keys Backend API Reference
Verification checklist
- Unauthorized user gets
403from ticket endpoint. - Expired ticket cannot be reused.
- Key create/rotate/revoke work inside iframe.
- Audit logs and analytics data are visible after actions.
