Demander une capability de workspace

Un membre admin demande une capability sensible (facturation, suppression, gestion des membres ou des réglages) que l'owner du compte propriétaire approuvera ensuite.

1 min de lectureTélécharger en PDF

Requête exemple

{
  "note": "J'ai besoin d'accéder à la facturation pour régulariser l'abonnement de fin d'année.",
  "capability": "can_manage_billing",
  "workspace_id": "ws_8f3a21c0"
}

Réponse exemple

{
  "ok": true,
  "request": {
    "id": "creq_4d9b17e2",
    "status": "pending",
    "capability": "can_manage_billing",
    "created_at": "2026-06-05T09:42:11.503Z"
  }
}

POST/v1/workspace/capability-requestsCréer une demande d'attribution de capability soumise à l'approbation de l'owner.

Crée une demande d'attribution de capability sur un workspace, suivant le flux « demande → approbation owner ». Un membre actif (typiquement un admin) demande une capability qu'il ne possède pas encore : la demande est enregistrée avec le statut pending, l'owner du compte propriétaire reçoit une notification par email, puis il approuve ou refuse. Seules les capabilities marquées comme demandables sont acceptées : can_manage_billing, can_delete_workspace, can_manage_members et can_manage_settings.

Authentification

Cette route s'authentifie via la session utilisateur (cookie Supabase), pas via une clé API à scope. Aucun scope spécifique n'est requis : il suffit d'une session valide. L'appelant doit en revanche être un membre actif du workspace, sans quoi la requête est refusée.

Corps de la requête

Champ	Type	Requis	Description
workspace_id	string	Oui	Identifiant du workspace sur lequel porte la demande.
capability	string	Oui	Capability demandée. Valeurs autorisées : `can_manage_billing`, `can_delete_workspace`, `can_manage_members`, `can_manage_settings`.
note	string	Non	Message libre justifiant la demande, transmis à l'owner. Espaces en bordure rognés ; vide est stocké comme `null`.

Réponse

En cas de succès, la réponse renvoie ok: true et un objet request contenant l'id de la demande, la capability visée, le status (toujours pending à la création) et l'horodatage created_at. La notification email à l'owner est envoyée en arrière-plan (fire-and-forget) : un échec d'envoi n'invalide pas la requête.

Erreurs

Code	Quand	Résolution
400	`workspace_id` ou `capability` manquant.	Fournir les deux champs dans le corps JSON.
400	La capability n'est pas demandable (`capability not requestable`).	N'utiliser que les quatre capabilities demandables listées ci-dessus.
400	L'appelant est déjà l'owner du compte propriétaire (`you are the account owner - you already have this`).	L'owner possède implicitement toutes les capabilities : aucune demande n'est nécessaire.
401	Aucune session utilisateur valide (`unauthorized`).	S'authentifier avant d'appeler la route.
403	L'appelant n'est pas membre actif du workspace (`not a member of this workspace`).	Rejoindre le workspace ou vérifier le `workspace_id`.
409	L'appelant possède déjà la capability (`you already have this capability`).	Aucune action : la capability est déjà accordée.
409	Une demande `pending` existe déjà pour cette capability (`a pending request already exists`).	Attendre la décision de l'owner sur la demande en cours.
500	Erreur d'insertion en base.	Réessayer ; si persistant, contacter le support.

Voir aussi

GET /v1/workspace/capability-requests — lister les demandes en attente.
Approuver ou refuser une demande de capability (inbox owner).
Gérer les membres et leurs capabilities sur un workspace.