Skip to main content
Version: v0.25.0 (Latest)

Owner Activation

Registering a tenant creates an owner bootstrap and mints a one-time owner invitation token, but the owner account is not yet usable. The owner activates it by redeeming that token and setting a credential. This is the last step that turns a registered tenant into a tenant whose owner can sign in.

The Invitation Token

The owner invitation token is minted server-side as part of tenant registration. It is delivered out of band:

  • Admin invite by email: the EDK hands the token to the enterprise-email-service server-side, which sends the owner an activation email containing the redemption link.
  • Admin direct creation without email: the operator hands the token to the owner through an out-of-band channel.

The token is never returned in any API response. Browser-visible responses redact it, and it is never stored in browser storage. The redemption endpoint and the credential are both write-only.

Redeeming the Invitation

The owner completes activation with POST /owner/redeem (redeemOwnerInvitation), submitting the one-time token plus the new credential they want to set. This endpoint is public and unauthenticated (security: []), because the owner has no account yet. The token itself is the proof of authorisation: it is one-time, scoped to a single owner bootstrap, and consumed on first successful redemption. On success the response identifies the activated owner and the tenant they own. The request and response schemas are in the Platform Admin API reference.

After redemption the owner account is active. The owner signs in through the tenant's authorization server and proceeds to configure the tenant's identity provider. See Tenant Federation.

Failure Modes

  • An unknown, already-redeemed, or expired token returns a 404.
  • A malformed request (missing token or credential, or a credential that fails the deployment's credential policy) returns the {error} validation envelope with 400.

Because the token is one-time, a second redemption attempt with the same token fails. If an owner never received or lost the invitation, the operator reissues it through the admin invite flow rather than re-exposing the original token.