Display name. Shown in the dashboard's app switcher and in transactional emails ({{appName}}).
Slug
URL-safe identifier — used in custom domain URLs and as a fallback display name. Cannot be changed after creation.
Description
Short blurb shown on the application overview. Internal-only.
Logo URL
Square logo. Used in admin UIs and email templates that don't already have full branding.
Contact email
Where users go for support. Surfaced in error pages and recovery flows.
Tenancy type
single or multi_tenant. Cannot be changed after creation — pick deliberately at app-creation time.
Tenancy mode
(multi-tenant only) shared or isolated. Cannot be changed after creation.
Setting the tenancy fields incorrectly at creation time is the most painful settings mistake — there's no in-place migration. Always think about whether your customers need cross-workspace identity (shared) or strict isolation (isolated) before clicking Create application.
For multi-tenant applications, a third section appears between General and Danger Zone: Tenant Customization. Four switches decide which surfaces tenants can override on their own:
Branding — Application or Per Tenant.
Email Templates — Application or Per Tenant.
Email Provider — Application or Per Tenant.
Isolated Auth Stack — Shared or Isolated. The big architectural toggle: when on, every tenant gets its own auth providers, password policy, MFA, and custom domain.
The full guide is on its own page: Tenancy Customization. It covers what each switch changes, when to flip them, and the cleanup needed when going from Isolated back to Shared.
The Danger Zone has actions that are either irreversible or shake the foundations of how the application works. Each one is gated by a confirmation dialog that requires you to type the application name.
Every user, tenant, role, policy, and resource scoped to it.
Every API key, M2M credential, and SAML connection.
Every active session.
Every email-template and branding override.
What survives:
The audit log entry for the deletion (kept for the standard retention window).
Aggregated analytics in your organization-level metrics (anonymized).
There's no undo. If you accidentally delete an application with live users, support can sometimes restore from a backup if the request comes within a short window — but plan to rebuild from scratch.
Move the application to another organization (e.g., when a customer's account is being merged with another). Requires the destination organization's ID and an out-of-band confirmation from a destination admin.
Users, roles, tenants, branding, and configuration travel with the application. API keys are not transferred — the destination team needs to rotate them after transfer (audit log captures this requirement).
A reversible alternative to deletion. Disabling stops every sign-in and revokes every active session, but keeps all configuration intact. Re-enable later to restore the application as-is.
curl -X POST https://your-app.authaz.io/api/v1/applications/{appId}/disable \ -H "X-API-Key: $AUTHAZ_API_KEY"curl -X POST https://your-app.authaz.io/api/v1/applications/{appId}/enable \ -H "X-API-Key: $AUTHAZ_API_KEY"
Use this for "we're winding down this product but might bring it back" or "we're investigating a security incident and need everything frozen."
The slug is forever. Pick something short and product-specific. It shows up in URLs and is harder to refactor than the display name.
Two-step confirmation. Every Danger Zone action requires typing the application name before the button enables. Don't paste it from a clipboard out of muscle memory — read what you're about to do.
Disable before delete. When you're not 100% sure deletion is right, disable first. Revisit in a week. If nothing went wrong (no panicked Slack messages), then delete.
Audit logs survive deletion. The "this application existed and someone deleted it" trail stays in your organization's audit log. Use that to reconstruct timelines if needed.
