Accounts, applications and workspaces

Use four different concepts deliberately: a person signs in, an account owns applications and data, an application calls the API, and a workspace organizes authorized business work.

Start without a naming wizard

For a new developer, verified signup prepares a Personal account, Default application and Default key behind the scenes. Naming and settings come later. This preparation creates no workspace, funding balance, paid work or provider connection.

Returning users reuse their existing authorized account/application context. If several eligible contexts make the choice ambiguous, the console asks which one you intend to use; it must not guess or silently create another account.

Preserve ownership

An application stays attached to its owning account. Its key is an application credential, not a human identity. Matching email addresses, workspace membership or platform staff privileges do not merge accounts, move balances or grant account administration.

Changes to membership and account status are checked independently of the developer session. A remembered account selector is not authority.

Work across workspaces

The planned business APIs will require explicit workspace or resource grants where relevant. An application may operate across multiple authorized workspaces; access to one does not grant access to every workspace or another account.

Developer signup and the first authentication check do not need an empty business workspace.

Financial boundaries

Applications do not receive a new wallet. Account and application cash-spend caps and prepaid-usage caps are independent optional policies, with no cap by default. Data access is separate from delegated payer authority, and prepaid auto-top-up requires explicit consent.

Verify account and application references returned by the API instead of inferring ownership from names. See Permissions before planning business access.