Applications

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

Endpoint	Description
POST /api/accounts/:account_id/applications	Create application under account
GET /api/accounts/:account_id/applications	List applications under account
GET /api/applications/:application_id	Retrieve application details
PATCH /api/applications/:application_id	Modify application settings
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"
}

Related

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