Hub documentation

Gestion programmatique du contrôle d'accès utilisateur

Hugging Face's logo
Join the Hugging Face community

and get access to the augmented documentation experience

to get started

Gestion programmatique du contrôle d'accès utilisateur

Ce guide décrit comment gérer les rôles des membres d’une organisation et l’appartenance aux groupes de ressources via l’API du Hub : modification du rôle d’organisation et des affectations de groupes de ressources d’un membre, liste des groupes de ressources, ajout d’utilisateurs à des groupes et flux de travail par lots.

Sommaire :


Changer le rôle d'un membre via l'API

Vous pouvez modifier le rôle d’organisation d’un membre (No Access / Read / Contributor / Write / Admin) et, le cas échéant, ses rôles dans les groupes de ressources à l’aide de l’API du Hub. L’API met à jour un membre par requête. Pour modifier les rôles de plusieurs membres, appelez l’API dans une boucle (exemples ci-dessous).

Référence OpenAPI : PUT /api/organizations/{name}/members/{username}/role

Prérequis

  • Votre organisation doit disposer d'un plan d'abonnement (par exemple Team ou Enterprise). Sinon, le point de terminaison renvoie 402.
  • Vous devez être authentifié en tant que membre de l'organisation disposant de l'autorisation Write (ou Admin) sur l'organisation.
  • L'utilisateur cible doit déjà être membre de l'organisation.

URL de base et authentification

  • URL de base : https://huggingface.co
  • Authentication: Envoyez votre jeton dans l'en-tête de la requête :
    Authorization: Bearer <your_access_token>
    Créez un jeton granulaire avec l'autorisation « Write access to organizations settings / member management » limitée à votre organisation sur https://huggingface.co/settings/tokens.

Point de terminaison pour changer le rôle d'un membre

Requête

PUT /api/organizations/{org_name}/members/{username}/role
Authorization: Bearer <your_access_token>
Content-Type: application/json

{
  "role": "read",
  "resourceGroups": []
}
  • Path parameters
    • org_name : identifiant de l’organisation (par ex. my-org).
    • username : username Hugging Face du membre dont vous modifiez le rôle.
  • Body
    • role (obligatoire) : le rôle du membre au niveau de l'organisation. L'une des valeurs suivantes : "no_access", "read", "contributor", "write" ou "admin".
    • resourceGroups (facultatif) : tableau des affectations de groupes de ressources pour cet utilisateur. Chaque élément :
      • id : ID du groupe de ressources (chaîne hexadécimale de 24 caractères ; obtenez les ID depuis l'API de la liste des groupes de ressources).
      • role : Rôle dans ce groupe de ressources : "read", "contributor", "write", "admin" ou "inherit".
    • Si vous omettez resourceGroups ou transmettez [], l'utilisateur est retiré de tous les groupes de ressources. Pour ne modifier que le rôle d'organisation et laisser les groupes de ressources inchangés, transmettez leurs affiliations actuelles aux groupes de ressources (le corps définit toujours à la fois le rôle d'organisation et la liste des groupes de ressources).

Exemple (curl) – définir le rôle d’organisation sur « read », sans groupes de ressources (supprime ceux dont l’utilisateur faisait précédemment partie)

curl -s -X PUT \
  -H "Authorization: Bearer $HF_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"role":"read","resourceGroups":[]}' \
  "https://huggingface.co/api/organizations/my-org/members/member1/role"

Exemple (curl) – définir le rôle d’organisation et les rôles de groupe de ressources (remplace tous les groupes actuels)

curl -s -X PUT \
  -H "Authorization: Bearer $HF_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"role":"write","resourceGroups":[{"id":"507f1f77bcf86cd799439011","role":"read"}]}' \
  "https://huggingface.co/api/organizations/my-org/members/member2/role"

Réponse de succès : statut 200 OK ; corps : { "success": true }.

Erreurs courantes

  • 400 — Corps invalide (par exemple, rôle ou identifiant de groupe de ressources id invalide).
  • 402 — L'organisation n'a pas d'abonnement.
  • 403 — Non autorisé (par exemple, vous n'avez pas les droits d'écriture sur l'organisation, ou un groupe de ressources n'appartient pas à l'organisation).
  • 404 — Organisation ou utilisateur introuvable.

Mise à jour de plusieurs membres

L'API modifie un membre par requête. Il n'existe pas de point d'accès en masse. Pour mettre à jour de nombreux membres, appelez le point d'accès une fois par nom d'utilisateur (par exemple à partir d'une liste ou d'un fichier CSV).

Exemple : Bash – boucle sur les noms d’utilisateurs, même rôle pour tous

ORG_NAME="my-org"
ROLE="read"
for username in member1 member2 member3 member4; do
  echo "Setting $username to $ROLE ..."
  curl -s -w "\n%{http_code}" -X PUT \
    -H "Authorization: Bearer $HF_TOKEN" \
    -H "Content-Type: application/json" \
    -d "{\"role\":\"$ROLE\",\"resourceGroups\":[]}" \
    "https://huggingface.co/api/organizations/$ORG_NAME/members/$username/role"
  echo ""
done

Exemple : Python – itérer sur les noms d’utilisateurs

import os
import requests

BASE_URL = "https://huggingface.co"
HF_TOKEN = os.environ.get("HF_TOKEN", "")

def change_member_role(org_name: str, username: str, role: str, resource_groups: list | None = None):
    payload = {"role": role, "resourceGroups": resource_groups or []}
    r = requests.put(
        f"{BASE_URL}/api/organizations/{org_name}/members/{username}/role",
        headers={"Authorization": f"Bearer {HF_TOKEN}", "Content-Type": "application/json"},
        json=payload,
    )
    if r.status_code != 200:
        raise RuntimeError(f"{r.status_code}: {r.text}")
    return r.json()

org_name = "my-org"
role = "read"
for username in ["member1", "member2", "member3", "member4"]:
    print(f"Setting {username} to {role} ... ", end="")
    try:
        change_member_role(org_name, username, role)
        print("OK")
    except Exception as e:
        print(f"Failed: {e}")

Pour attribuer des rôles différents à chaque utilisateur, itérez sur les paires (username, role) (par exemple issues d'un CSV) et appelez change_member_role pour chacune.


API des groupes de ressources

Les points de terminaison suivants vous permettent de lister les groupes de ressources et d’ajouter des utilisateurs à ceux-ci. Pour modifier le rôle au niveau de l’organisation d’un membre existant ou ses affectations de groupes de ressources, consultez Modifier le rôle d’un membre via l’API ci-dessus.

Référence OpenAPI : Groupes de ressources

Sommaire — Approches API :

ObjectifSection
Ajouter de nombreux utilisateurs à un groupe de ressourcesAjouter des utilisateurs à un groupe de ressources
Ajouter les mêmes utilisateurs à de nombreux groupes de ressourcesAjout par lots en boucle sur l'API
Ajouter des différents utilisateurs par groupeAjout par lots en boucle sur l'API

URL de base et authentification

  • URL de base : https://huggingface.co
  • Authentication: Utilisez l'une des options suivantes :
    • Access token (recommended for scripts): Créez un jeton granulaire avec l'autorisation « Write access to organizations settings / member management » limitée à votre organisation sur https://huggingface.co/settings/tokens. Envoyez-le dans l'en-tête de la requête :
      Authorization: Bearer <your_access_token>
    • Cookie de session : Si l'appel est effectué depuis un navigateur ou un outil partageant la même session que l'interface du Hub, le cookie est envoyé automatiquement.

Lister les groupes de ressources

Récupérez tous les groupes de ressources que vous pouvez gérer pour l’organisation. Utilisez cette information pour obtenir l’id de chaque groupe pour les appels add-users.

Requête

GET /api/organizations/{org_name}/resource-groups
Authorization: Bearer <your_access_token>

Exemple (curl)

curl -s -H "Authorization: Bearer $HF_TOKEN" \
  "https://huggingface.co/api/organizations/my-org/resource-groups"

Exemple de réponse (tronquée)

[
  {
    "id": "507f1f77bcf86cd799439011",
    "name": "Cohort 2024",
    "description": "Members in this group",
    "users": [...],
    "repos": [...]
  }
]

Utilisez l'id de chaque groupe de ressources lors de l'ajout d'utilisateurs.

Ajouter des utilisateurs à un groupe de ressources

Ajoutez un ou plusieurs utilisateurs à un groupe de ressources unique dans une seule requête. Vous pouvez envoyer plusieurs utilisateurs dans la même requête.

Requête

POST /api/organizations/{org_name}/resource-groups/{resource_group_id}/users
Authorization: Bearer <your_access_token>
Content-Type: application/json

{
  "users": [
    { "user": "member1", "role": "read" },
    { "user": "member2", "role": "read" },
    { "user": "member3", "role": "write" }
  ]
}
  • Path parameters
    • org_name : identifiant de l’organisation (par ex. my-org).
    • resource_group_id : l'id du groupe de ressources (chaîne hexadécimale de 24 caractères issue de l'endpoint de liste).
  • Body
    • users: Tableau d'objets. Chaque objet doit contenir :
      • user : nom d'utilisateur Hugging Face username (obligatoire).
      • role : L’un des éléments suivants : "read", "contributor", "write", "admin" ou "inherit".

Exemple (curl)

curl -s -X POST \
  -H "Authorization: Bearer $HF_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"users":[{"user":"member1","role":"read"},{"user":"member2","role":"read"}]}' \
  "https://huggingface.co/api/organizations/my-org/resource-groups/507f1f77bcf86cd799439011/users"

Succès : statut 200 OK ; le corps de la réponse est l’objet de groupe de ressources mis à jour (contient les nouveaux utilisateurs dans users).

Erreurs typiques :

  • 400 — par exemple, utilisateur introuvable, noms d'utilisateur en double ou corps de requête invalide.
  • 403 — Non autorisé (par exemple, l'utilisateur ne fait pas partie de l'organisation ou est déjà dans le groupe de ressources). Le message indiquera si les utilisateurs ne font pas partie de l'organisation ou s'ils sont déjà dans le groupe.

Ajout de membres par e-mail (solution de contournement)

L'endpoint add-users n'accepte que des noms d'utilisateur Hugging Face, pas des adresses e-mail. Si vous disposez d'une liste d'adresses e-mail (par exemple, les e-mails des membres), vous pouvez d'abord résoudre e-mail → nom d'utilisateur, puis appeler l'API add-users.

Notez que le filtrage par e-mail ne fonctionne que lorsque le domaine de l’adresse e-mail correspond à l’un des domaines autorisés de l’organisation : le domaine e-mail de l’organisation (Paramètres → Compte → Domaine e-mail de l’organisation) et/ou les domaines autorisés SSO de l’organisation (si le SSO est configuré).

Étape 1 – Résoudre l’adresse e-mail en nom d’utilisateur

GET /api/organizations/{org_name}/members?email={email}&limit=1
Authorization: Bearer <your_access_token>

La réponse est un tableau de membres ; chaque membre possède user (nom d'utilisateur). Utilisez user pour l'appel add-users.

Étape 2 – Ajouter au groupe de ressources

Utilisez le nom d'utilisateur de l'étape 1 dans une requête add-users standard :

POST /api/organizations/{org_name}/resource-groups/{resource_group_id}/users
Content-Type: application/json
Body: { "users": [{ "user": "<username from step 1>", "role": "read" }] }

Exemple : un e-mail (bash)

ORG_NAME="my-org"
RG_ID="507f1f77bcf86cd799439011"
EMAIL="member@org.com"

# Step 1: look up member by email (domain must match org's Organization email domain or SSO allowed domains)
MEMBERS=$(curl -s -H "Authorization: Bearer $HF_TOKEN" \
  "https://huggingface.co/api/organizations/$ORG_NAME/members?email=$EMAIL&limit=1")
USERNAME=$(echo "$MEMBERS" | jq -r '(.[0] // {} | .user // "")')
if [ -z "$USERNAME" ]; then
  echo "No member found for $EMAIL"
  exit 1
fi
# Step 2: add to resource group
curl -s -X POST -H "Authorization: Bearer $HF_TOKEN" -H "Content-Type: application/json" \
  -d "{\"users\":[{\"user\":\"$USERNAME\",\"role\":\"read\"}]}" \
  "https://huggingface.co/api/organizations/$ORG_NAME/resource-groups/$RG_ID/users"

Exemple : plusieurs e-mails dans une boucle (Python)

import os
import requests

BASE = "https://huggingface.co"
ORG = "my-org"
RG_ID = "507f1f77bcf86cd799439011"
ROLE = "read"
headers = {"Authorization": f"Bearer {os.environ['HF_TOKEN']}", "Content-Type": "application/json"}

emails = ["member1@org.com", "member2@org.com"]
for email in emails:
    # Step 1: resolve email → username (email domain must match org's Organization email domain or SSO allowed domains)
    r = requests.get(f"{BASE}/api/organizations/{ORG}/members", params={"email": email, "limit": 1}, headers=headers)
    r.raise_for_status()
    members = r.json()
    if not members:
        print(f"No member found for {email}")
        continue
    username = members[0]["user"]
    # Step 2: add that user to the resource group
    add_r = requests.post(
        f"{BASE}/api/organizations/{ORG}/resource-groups/{RG_ID}/users",
        headers=headers,
        json={"users": [{"user": username, "role": ROLE}]},
    )
    if add_r.status_code == 200:
        print(f"Added {username} ({email})")
    else:
        print(f"Failed {email}: {add_r.status_code} {add_r.text}")

Si un utilisateur est déjà présent dans le groupe de ressources, l'appel d'ajout renvoie 403 ; le script le signale comme un échec et vous pouvez ignorer ou passer ce cas si vous le préférez.

Limitation : le filtre d’adresse e-mail ne s’applique que lorsque l’organisation a défini un domaine d’e-mail d’organisation et/ou des domaines autorisés pour le SSO, et que le domaine de l’adresse e-mail correspond à l’un d’eux. Sinon, vous ne pouvez pas effectuer de recherche par e-mail via l’API des membres ; vous aurez besoin d’une autre source pour l’association e-mail → nom d’utilisateur (par exemple, votre propre annuaire).

Ajout par lot en boucle sur l'API

Vous pouvez ajouter de nombreux utilisateurs à un groupe de ressources dans une ou quelques requêtes (par exemple, en découpant votre liste de noms d’utilisateurs), ou ajouter des utilisateurs à plusieurs groupes de ressources en parcourant les groupes et en appelant le point de terminaison add-users pour chacun.

Exemple : Bash – un groupe, plusieurs utilisateurs dans une seule requête

#!/bin/bash
# Add a list of users to a single resource group.
# Usage: ./add-users-to-rg.sh <org_name> <resource_group_id> <role>

ORG_NAME="${1:-my-org}"
RG_ID="${2:-507f1f77bcf86cd799439011}"
ROLE="${3:-read}"

USERS="member1 member2 member3 member4"
USERS_JSON=$(echo "$USERS" | tr ' ' '\n' | while read u; do
  [ -n "$u" ] && echo "{\"user\":\"$u\",\"role\":\"$ROLE\"}"
done | paste -sd ',' -)

curl -s -w "\nHTTP_STATUS:%{http_code}" -X POST \
  -H "Authorization: Bearer $HF_TOKEN" \
  -H "Content-Type: application/json" \
  -d "{\"users\":[$USERS_JSON]}" \
  "https://huggingface.co/api/organizations/$ORG_NAME/resource-groups/$RG_ID/users"

Exemple : Bash – itérer sur plusieurs groupes

# Get group IDs and add users to each
curl -s -H "Authorization: Bearer $HF_TOKEN" \
  "https://huggingface.co/api/organizations/my-org/resource-groups" \
  | jq -r '.[].id' \
  | while read -r RG_ID; do
      [ -z "$RG_ID" ] && continue
      echo "Adding users to resource group $RG_ID ..."
      curl -s -X POST -H "Authorization: Bearer $HF_TOKEN" -H "Content-Type: application/json" \
        -d "{\"users\":[$USERS_JSON]}" \
        "https://huggingface.co/api/organizations/my-org/resource-groups/$RG_ID/users"
    done

Exemple : Python – ajout par lot à un ou plusieurs groupes

import os
import requests

BASE_URL = "https://huggingface.co"
HF_TOKEN = os.environ.get("HF_TOKEN", "")

def list_resource_groups(org_name: str):
    r = requests.get(
        f"{BASE_URL}/api/organizations/{org_name}/resource-groups",
        headers={"Authorization": f"Bearer {HF_TOKEN}"},
    )
    r.raise_for_status()
    return r.json()

def add_users_to_resource_group(org_name: str, resource_group_id: str, users_with_roles: list):
    """users_with_roles: list of {"user": "username", "role": "read"|"write"|"contributor"|"admin"}"""
    r = requests.post(
        f"{BASE_URL}/api/organizations/{org_name}/resource-groups/{resource_group_id}/users",
        headers={"Authorization": f"Bearer {HF_TOKEN}", "Content-Type": "application/json"},
        json={"users": users_with_roles},
    )
    if r.status_code != 200:
        raise RuntimeError(f"Add users failed {r.status_code}: {r.text}")
    return r.json()

# Example: same users added to every resource group
org_name = "my-org"
role = "read"
usernames = ["member1", "member2", "member3"]
users_with_roles = [{"user": u, "role": role} for u in usernames]

for rg in list_resource_groups(org_name):
    add_users_to_resource_group(org_name, rg["id"], users_with_roles)

Pour une longue liste de noms d’utilisateur, découpez-la (par exemple, 50 par requête) et appelez l’API une fois par bloc afin d’éviter les corps de requête volumineux ou les dépassements de délai.

Remarques importantes

  1. Noms d’utilisateur uniquement — L’API accepte les noms d’utilisateur Hugging Face, et non les adresses e-mail. Vous devez disposer d’une correspondance entre e-mail et nom d’utilisateur (par exemple, à partir de votre annuaire ou de la liste des membres de l’organisation) avant d’appeler l’API.
  2. Les utilisateurs doivent appartenir à l’organisation — Chaque utilisateur de la requête doit déjà être membre de l’organisation. Sinon, la requête renvoie 403 avec un message indiquant que certains utilisateurs ne font pas partie de l’organisation.
  3. Idempotence — Si un utilisateur est déjà présent dans le groupe de ressources, l’arrière-plan peut renvoyer 403 pour cette requête. Votre script peut capturer les erreurs et continuer, ou ignorer les utilisateurs déjà présents dans le groupe si vous récupérez d’abord la liste users du groupe.
  4. Limites de débit — Pour les lots volumineux, envisagez d'ajouter un court délai entre les requêtes (par exemple 0,5 à 1 seconde) afin d'éviter d'atteindre les limites de débit.
  5. Portée du jeton — Le jeton d'accès doit disposer de permissions suffisantes pour l'organisation (généralement au moins « Accès en écriture aux paramètres de l'organisation / gestion des membres »). Créez et stockez le jeton de manière sécurisée ; ne le committez pas dans le contrôle de version.

Configurer l'auto-join via l'API

Auto-join ajoute automatiquement les membres de l’organisation à un Resource Group avec un rôle spécifié. Vous pouvez l’activer ou le désactiver via l’API et choisir, le cas échéant, d’inclure tous les membres de l’organisation ou uniquement les membres Read+.

Activer l'auto-rejoindre

POST /api/organizations/{org_name}/resource-groups/{resource_group_id}/settings
Authorization: Bearer <your_access_token>
Content-Type: application/json

{
  "autoJoin": {
    "enabled": true,
    "role": "read",
    "scope": "read_plus"
  }
}
  • Path parameters
  • Body
    • role : Le rôle à attribuer aux membres ajoutés automatiquement. L’un des "read", "contributor", "write", "admin" ou "inherit".
    • scope (facultatif) : Membres de l’organisation à ajouter automatiquement. Utilisez "all" pour inclure tous les membres de l’organisation. Utilisez "read_plus" pour exclure les membres ayant le rôle d’organisation no_access. La valeur par défaut est "all" si ce paramètre est omis.

Activer l’auto-join sur un groupe de ressources existant ajoute immédiatement les membres actuels de l’organisation correspondant à la portée sélectionnée (rétroactivité).

Désactiver l'auto-rejoindre

Envoyez la même requête avec "enabled": false. Le champ role n'est pas requis lors de la désactivation :

POST /api/organizations/{org_name}/resource-groups/{resource_group_id}/settings
Authorization: Bearer <your_access_token>
Content-Type: application/json

{
  "autoJoin": {
    "enabled": false
  }
}

La désactivation de l’auto-ajout ne supprime pas les membres qui avaient été ajoutés automatiquement auparavant. Elle empêche uniquement l’ajout automatique des futurs membres de l’organisation. Les membres existants restent dans le Resource Group.

Définir des limites de dépenses via l'API

Les limites de dépense plafonnent la dépense de calcul mensuelle attribuée à un groupe de ressources. Définissez-les avec le point de terminaison de mise à jour :

PATCH /api/organizations/{org_name}/resource-groups/{resource_group_id}
Authorization: Bearer <your_access_token>
Content-Type: application/json

{
  "spendLimits": {
    "total": 500000,
    "spaces": 100000,
    "jobs": 50000
  }
}
  • Path parameters
  • Body
    • spendLimits: Limites mensuelles en centimes. L'exemple ci-dessus définit une limite totale de 5 000 $, avec 1 000 $ pour Spaces et 500 $ pour Jobs.
      • total : Limite de la dépense cumulée du groupe sur l’ensemble des produits.
      • inferenceProviders, spaces, jobs, endpoints : limites par produit, appliquées en plus du total. La plus stricte des deux s’applique.

Seules les clés que vous envoyez sont mises à jour, les autres conservent leur valeur actuelle. Envoyez null pour supprimer une limite :

PATCH /api/organizations/{org_name}/resource-groups/{resource_group_id}
Authorization: Bearer <your_access_token>
Content-Type: application/json

{
  "spendLimits": {
    "jobs": null
  }
}

Exemple (curl)

curl -s -X PATCH \
  -H "Authorization: Bearer $HF_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"spendLimits": {"total": 500000}}' \
  "https://huggingface.co/api/organizations/my-org/resource-groups/507f1f77bcf86cd799439011"

La réponse est le groupe de ressources mis à jour, y compris ses spendLimits.

Inviter des collaborateurs externes via l'API

Invitations externes permettent aux administrateurs de groupes de ressources d’inviter des utilisateurs extérieurs à l’organisation à rejoindre un groupe de ressources. Les invités rejoignent en tant que collaborateurs externes avec le rôle d’organisation no_access. Ils comptent dans le nombre de sièges payants de votre organisation.

Activer les invitations externes

Les administrateurs d'organisation peuvent activer le paramètre avec :

POST /api/organizations/{org_name}/resource-groups/settings
Authorization: Bearer <your_access_token>
Content-Type: application/json

{
  "allowExternalInvites": true
}
  • Body
    • allowExternalInvites (facultatif) : Indique si les administrateurs du groupe de ressources peuvent inviter des utilisateurs extérieurs à l’organisation.
    • minRoleToCreate (facultatif) : Rôle minimal de l’organisation requis pour créer des Resource Groups.

Les champs omis sont laissés inchangés. Utilisez GET /api/organizations/{org_name}/resource-groups/settings pour lire les paramètres actuels.

Inviter un utilisateur

POST /api/organizations/{org_name}/resource-groups/{resource_group_id}/invite
Authorization: Bearer <your_access_token>
Content-Type: application/json

{
  "username": "partner-user",
  "role": "read"
}
  • Path parameters
  • Body
    • username : Nom d'utilisateur d'un utilisateur Hugging Face existant qui n'est pas encore membre de l'organisation. Pour ajouter un membre de l'organisation, utilisez plutôt Ajouter des utilisateurs à un groupe de ressources.
    • role : Rôle attribué à l’invité dans le groupe de ressources, "read" ou "write".

L'utilisateur reçoit une invitation par e-mail et un accès au Resource Group après l'avoir acceptée.

Gérer les invitations en attente

  • Liste : GET /api/organizations/{org_name}/resource-groups/{resource_group_id}/invitations
  • Renvoyer : POST /api/organizations/{org_name}/resource-groups/{resource_group_id}/invitation/{invitation_id}/resend
  • Révoquer : DELETE /api/organizations/{org_name}/resource-groups/{resource_group_id}/invitation/{invitation_id}

Vous pouvez également consulter la spécification OpenAPI complète

Erreurs typiques :

  • 403 — Les invitations externes ne sont pas activées pour l'organisation.
  • 409 — L'utilisateur est déjà membre de l'organisation ou a déjà une invitation en attente.

Changer le type de compte de membre via l'API

Transformez un membre de l’organisation en collaborateur externe (aucune SSO requise) ou convertissez-le à nouveau en membre. Nécessite un plan payant et la permission Write (ou Admin) sur l’organisation. Non disponible dans les organisations avec des utilisateurs gérés, où les membres sont provisionnés via SCIM.

Changer le type de compte d’un utilisateur ne modifie pas son rôle. Consultez Changer le rôle d’un membre via l’API pour modifier le rôle d’un utilisateur.

PUT /api/organizations/{org_name}/members/{username}/account-type
Authorization: Bearer <your_access_token>
Content-Type: application/json

{
  "accountType": "external"
}
  • Body
    • accountType : "external" pour convertir le membre en collaborateur externe, ou "member" pour le convertir à nouveau en membre.
Update on GitHub