Applications

Les applications définissent des limites de service et des namespaces d’utilisateurs. Chaque utilisateur, client et marchand appartient à une application. Les comptes vivent sous les applications et représentent des limites de facturation et d’équipe.

La hiérarchie alterne :

Application → Account → Application → Account

Cela signifie que chaque application est son propre namespace d’utilisateurs. Le même email peut exister dans plusieurs applications sans conflit.

Pourquoi c’est important

La création d’utilisateurs se fait dans l’application parente du compte cible.
Les access tokens portent le contexte application et compte, pas un claim d’espace de noms séparé.
L’isolation est assurée par les limites d’application et les memberships de compte.

Exemple de hiérarchie

app_platform
  └─ acc_alice
       └─ app_taskflow
            └─ acc_bob

app_platform possède Alice en tant qu’utilisateur.
app_taskflow possède Bob en tant qu’utilisateur.
acc_bob est facturé sous app_taskflow.

Opérations sur les applications

Opération	Endpoint	Description
Créer	`POST /api/accounts/:account_id/applications`	Créer une application sous un compte
Lister	`GET /api/accounts/:account_id/applications`	Lister les applications d’un compte
Obtenir	`GET /api/applications/:application_id`	Obtenir les détails d’une application
Mettre à jour	`PATCH /api/applications/:application_id`	Modifier la configuration
Supprimer	`DELETE /api/applications/:application_id`	Supprimer une application

Claims du token

Les tokens incluent le contexte application et compte :

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

Liens associés

Comptes - Limites de facturation et d’équipe
Utilisateurs - Cycle de vie des utilisateurs
Membership - Liens utilisateur-compte
Compte - Ressource compte