Applications

Applications define service boundaries and user namespaces. Every user, client, and merchant belongs to an Application. Accounts live under Applications and represent billing/team boundaries.

The hierarchy alternates:

Application → Account → Application → Account

That means each Application is its own user namespace. The same email can exist in multiple Applications without conflict.

Why This Matters

User creation happens in the parent Application of the target Account.
Access tokens carry the Application and Account context, not a separate namespace claim.
Isolation is enforced by Application boundaries and account memberships.

Example Hierarchy

app_platform
  └─ acc_alice
       └─ app_taskflow
            └─ acc_bob

app_platform owns Alice as a user.
app_taskflow owns Bob as a user.
acc_bob is billed under app_taskflow.

Application Operations

Operation	Endpoint	Description
Create	`POST /api/accounts/:account_id/applications`	Create application under account
List	`GET /api/accounts/:account_id/applications`	List applications under account
Get	`GET /api/applications/:application_id`	Retrieve application details
Update	`PATCH /api/applications/:application_id`	Modify application settings
Delete	`DELETE /api/applications/:application_id`	Remove application

Token Claims

Tokens include application and account context:

{
  "app": "app_root",
  "acc": "acc_child456",
  "uid": "uid_789",
  "role": "member"
}

Accounts - Billing and team boundaries
Users - User lifecycle in an application
Membership - User to account links
Account - Account resource

Applications

Why This Matters

Example Hierarchy

Application Operations

Token Claims

Related