The developer Console.

The Console lives at https://elvix.is/console. It is where a developer configures an Application. Everything here is also reachable over the REST API (see the Developers guide) and the MCP, so an agent can do the same things programmatically.

Application settings tabs

Each Application has tabs at /console/applications/<id>/. What each one controls:

• Branding: app name, light+dark logo, light+dark icon, brand colour.
• Domains & redirects: app type(s) (web/mobile/api), primary domain, redirect URIs, allowed origins (CORS).
• Sign-in methods: toggle Google, Email OTP, Passkey, Username; layout, presentation, theme. At least one method must be enabled.
• Legal: Privacy Policy URL, Terms of Service URL (both probed for a 2xx), support email.
• Credentials: view the clientId, rotate the client secret (shown once, the old one stops immediately), and the Endpoints block (base URL, sign-in URL, plus the token and API-key verify endpoints). Session tokens are opaque — verify one with POST /api/v1/session. A backend that wants local verification instead exchanges it once via POST /api/v1/token for a signed RS256 JWT, then points any OIDC resource server at https://elvix.is: both /.well-known/jwks.json and /.well-known/openid-configuration are served. See the Verify on your backend guide.
• Sessions: session TTL (days) and renewal interval for this app's users.
• Sign-in gate (limited access): public (anyone), private_beta (allowlist), closed (existing members only) + the beta-interest list.
• Publish / Lifecycle: the readiness checklist and the draft → test → live ladder; archive, unarchive, delete (90-day grace), restore.

People + access

• Users: list, invite, open a user to see sign-in history, profile, sessions, activity, and to block / deactivate / delete them.
• Roles / Scopes / Memberships: three independent catalogs. Create, edit, reorder by priority, mark one default (default is backfilled to all users). Grant/revoke per user. Roles = security, Scopes = purposes, Memberships = tiers.
• API keys (eak_): two scopes. PER-APPLICATION keys live on this tab and carry per-key roles, scopes, memberships. WORKSPACE keys live at the workspace-level Console > API keys page and reach every app in the workspace (or a chosen subset) for agents / the MCP / back-office tools. Both support Read or Full (read + write) access, rotate (with a grace window), revoke, rate limits, and usage. Each key carries a source of console (minted here) or device (granted by a CLI device-login such as plm login); device-granted keys are also revocable by the user from their Account > Connected devices. Each key also has a Connected devices tab: every distinct caller that authenticated with it (parsed client + user-agent, country, first and last seen, request count), captured from the verify endpoint.
• Webhooks: add an endpoint, choose events, test delivery, inspect deliveries. Signed with an HMAC secret (verify with verifyElvixWebhook).
• Activity / Logs / Insights: auth-event log, per-user logs, aggregated analytics.

Taking an app live (publish requirements)

An Application moves draft → test → live. POST /api/applications/<id>/publish promotes draft → test; POST /api/applications/<id>/go-live promotes test → live. Both re-validate readiness and reject server-side if anything is missing, so an agent cannot force an app live with an incomplete config.

All of these must be satisfied before publish or go-live succeeds:

• App name (at least 2 characters).
• Light and dark logo, light and dark icon (uploaded).
• At least one app type (web / mobile / api).
• A primary domain.
• At least one redirect URI (no wildcards; http only for localhost).
• At least one sign-in method enabled.
• Privacy Policy URL and Terms of Service URL that each return 2xx (elvix probes them).
• A support email.