Membres et équipes

Rôles

Chaque membre d’une organisation a exactement un rôle au niveau de l’organisation.

Une organisation doit avoir au moins un propriétaire en permanence. Vous ne pouvez ni retirer ni rétrograder le dernier propriétaire.

Comment la facturation d’un utilisateur est décidée

Une seule règle couvre tous les rôles ci-dessus :

Vous êtes un utilisateur facturable si vous pouvez écrire quelque part. Si tout ce que vous détenez est en lecture seule — ou si vous ne détenez rien — vous êtes gratuit. La seule exception est l’équipe Auditors : ses 5 premiers membres en lecture seule sont gratuits, et chacun des suivants est un utilisateur facturable.

En dehors des auditeurs, c’est la permission accordée par vos équipes qui décide, et non leur nom. Une équipe en lecture seule que vous créez vous-même est donc gratuite quelle que soit sa portée, et renommer une équipe ne change jamais ce que vous payez. Les propriétaires, membres et collaborateurs peuvent écrire, ils sont donc facturables ; les lecteurs et invités ne le peuvent pas, ils ne le sont donc pas.

Inviter des membres

La gestion des membres se trouve dans l’interface d’administration de fremforge, à /<org>/_admin/members — la page Membres liste chaque membre actuel, avec pour chacun un tiroir Gérer, et une boîte de dialogue d’invitation en haut. La page native de Forgejo frem.sh/org/<org>/teams reste disponible en solution de repli lorsque vous devez composer des permissions d’équipe plus fines ; la page du produit couvre le flux quotidien d’invitation, de rôle et de retrait.

1. Allez dans Administration de l’organisation → Membres (/<org>/_admin/members).
2. Cliquez sur Inviter par e-mail.
3. Saisissez le nom d’utilisateur ou l’adresse e-mail de la personne invitée et choisissez un rôle.
4. Cliquez sur Envoyer l’invitation.

La personne invitée reçoit un e-mail de noreply@frem.sh contenant un lien d’acceptation. Le lien est valable 7 jours. S’il expire, renvoyez-le depuis la section Invitations en attente de la même page.

Dans la section Invitations en attente, la personne invitée apparaît comme En attente jusqu’à ce qu’elle accepte. Les membres en attente :

• N’ont accès à aucune ressource de l’organisation.
• Ne comptent pas comme utilisateur facturable tant qu’ils n’ont pas accepté l’invitation.
• Peuvent être annulés à tout moment en les retirant de l’équipe tant qu’ils sont en attente.

Une fois que la personne invitée a accepté, son statut passe à Actif et elle est ajoutée au nombre d’utilisateurs facturables au cycle de facturation suivant. Aucune activité n’est requise : c’est l’acceptation qui compte.

Lecteurs gratuits (lecture seule, non facturables)

Un lecteur a un accès en lecture seule aux dépôts qui lui sont attribués — cloner, parcourir le code, lire les tickets et les pull requests — mais ne peut pas pousser, créer de dépôts ni accéder aux paramètres d’administration de l’organisation. Les lecteurs sont gratuits : ils ne comptent pas dans votre plafond d’utilisateurs et ne sont jamais facturés. Ajoutez-en autant que vous voulez — parties prenantes, prestataires qui n’ont besoin que de regarder, tableaux de bord en lecture seule, etc. Une personne qui doit aussi lire les paramètres de votre organisation, comme un auditeur de conformité, a plutôt sa place dans Auditors.

Concrètement, un lecteur est membre de l’équipe canonique Viewers de l’organisation et d’aucune équipe qui accorde l’écriture. Le décompte des utilisateurs suit la permission accordée par une équipe, et non son nom : ne détenez que des équipes en lecture seule et vous êtes gratuit ; détenez l’écriture n’importe où et vous êtes facturé. (Si vous ajoutez quelqu’un à Viewers et à Members, il est facturé — l’écriture l’emporte.)

Comme la règle repose sur la permission et non sur le nom, une équipe en lecture seule que vous créez vous-même — Stakeholders, Reviewers, quel que soit son nom — est également gratuite, et la limiter à quelques dépôts n’y change rien. Utilisez les invités lorsque c’est exactement ce que vous voulez : la lecture gratuite, sur des dépôts choisis. L’équipe canonique Auditors n’en fait pas partie : fremforge la crée, elle donne accès aux paramètres de l’organisation en plus du code, et seuls ses 5 premiers membres sont gratuits (voir Auditeurs).

Ajouter un lecteur

Chacune de ces méthodes fonctionne ; la voie du produit est la plus simple :

1. Depuis la page Membres (recommandé). Allez dans Administration de l’organisation → Membres (/<org>/_admin/members) → Inviter par e-mail → saisissez l’e-mail → dans Équipe(s), sélectionnez Viewers (et rien d’autre) → Envoyer l’invitation. Lorsqu’elle accepte, la personne rejoint l’organisation comme lecteur gratuit.
2. Convertir un membre existant. Ouvrez le tiroir Gérer du membre et déplacez-le vers Viewers (retirez-le de Members/Owners). Il sort du nombre d’utilisateurs facturables au cycle de facturation suivant.
3. Automatiquement via le SSO. Associez un groupe du fournisseur d’identité à l’équipe Viewers (voir SSO et SCIM). Toutes les personnes de ce groupe sont provisionnées comme lecteurs gratuits — aucune invitation individuelle n’est nécessaire.
4. Solution de repli native Forgejo. frem.sh/org/<org>/teams → Viewers → Add team member. N’utilisez cette voie que si vous avez besoin d’une composition d’équipe plus fine ; la page Membres couvre le cas normal.

Les lecteurs gratuits sont comptés séparément des utilisateurs payants dans votre récapitulatif de facturation (Administration de l’organisation → Facturation) et dans l’API des utilisateurs, de sorte que vous voyez toujours combien de lecteurs gratuits vous avez par rapport au nombre d’utilisateurs facturables.

À ne pas confondre avec un lecteur de documentation uniquement. Si vous voulez qu’une personne puisse lire votre documentation publiée sans aucun accès aux dépôts et sans aucun compte Forgejo, ne l’ajoutez pas à Viewers — donnez plutôt à son groupe SSO une association groupe→équipe vide. Voir Wiki et documentation publique. Un lecteur (équipe Viewers) obtient un compte Forgejo et un accès en lecture aux dépôts attribués ; un lecteur de documentation uniquement, non.

Invités (lecture gratuite, dépôts précis)

Un lecteur peut lire tous les dépôts de l’organisation. Un invité ne lit que les dépôts que vous choisissez. Les deux sont gratuits — lire du code ne coûte jamais d’utilisateur facturable, quelle qu’en soit la portée.

Utilisez les invités pour un prestataire qui examine un seul service, un auditeur qui a besoin de deux dépôts plutôt que de quarante, ou une équipe partenaire que vous voulez tenir à l’écart de tout le reste. C’est la version à moindre privilège d’un lecteur, et elle coûte la même chose : rien.

Les invités forment l’équipe canonique Guests, créée dans chaque organisation et limitée à des dépôts précis plutôt qu’à tous.

Ajouter un invité

1. Allez dans Administration de l’organisation → Membres → Inviter par e-mail → saisissez l’e-mail → dans Équipe(s), sélectionnez Guests (et rien d’autre).
2. Choisissez les dépôts que l’équipe Guests peut lire : frem.sh/org/<org>/teams/guests → Repositories → ajoutez les dépôts voulus.
3. Envoyez l’invitation. Lorsqu’elle accepte, la personne peut lire exactement ces dépôts.

Pour restreindre un lecteur gratuit existant à des dépôts précis, ouvrez son tiroir Gérer et déplacez-le de Viewers vers Guests. Il reste gratuit dans les deux cas.

Guests et Collaborators sont gérées par fremforge et ne peuvent pas être supprimées. Elles déterminent ce que vous payez — Guests maintient gratuits les lecteurs limités à certains dépôts, Collaborators est ce qui fait d’une personne ayant un accès en écriture limité à certains dépôts un utilisateur payant. Supprimer l’une ou l’autre modifierait silencieusement la tarification de votre organisation ; les deux sont donc verrouillées, comme Members et Viewers. Vous pouvez librement changer les dépôts que chacune couvre, ainsi que ses membres.

Auditeurs

Un auditeur peut tout consulter dans votre organisation et ne rien modifier. Utilisez ce rôle pour un auditeur de conformité ou de sécurité, une fonction de contrôle interne, ou toute personne qui doit examiner la configuration de l’organisation plutôt que simplement lire son code.

Chaque organisation possède une équipe canonique Auditors, créée et gérée par fremforge. Elle dispose d’un accès en lecture à tous les dépôts, et ses membres peuvent aussi ouvrir les paramètres d’administration de l’organisation. Comme les autres équipes canoniques, elle est verrouillée : vous ne pouvez ni la supprimer, ni la renommer, ni lui donner plus qu’un accès en lecture. C’est un propriétaire qui décide qui en fait partie.

Ce qu’un auditeur peut voir

• Chaque dépôt, en lecture seule, comme un lecteur : cloner, parcourir le code, lire les tickets et les pull requests.
• Les paramètres d’administration de l’organisation à /<org>/_admin/ et les lectures correspondantes de l’API REST : politiques, paramètres de sécurité, SSO, membres, facturation et journal d’audit. Cela inclut ce qu’un propriétaire voit sur les personnes : sur la page Membres, les adresses e-mail, noms complets, dernière connexion et statut MFA des membres, et dans les paramètres de facturation, le contact de facturation et les identifiants de mandat de paiement.
• Les paramètres de l’organisation et des dépôts dans Forgejo (frem.sh/org/<org>/settings, les Paramètres d’un dépôt), en lecture seule.
• Les preuves de conformité et les attestations. Un auditeur peut les récupérer ; chaque récupération est enregistrée dans le journal d’audit.

Un bandeau sur chaque page d’administration indique que vous consultez en tant qu’auditeur en lecture seule. Les boutons et formulaires qui modifieraient quelque chose sont désactivés.

Ce qu’un auditeur ne peut pas faire

• Modifier quoi que ce soit. Toute requête autre qu’une lecture est refusée, dans les pages d’administration, sur l’API et dans Forgejo, avant d’atteindre le point de terminaison. Sur l’API fremforge, le refus est un 403 avec l’erreur auditor-read-only. Un auditeur ne peut ni ajouter ni retirer de membres, y compris d’autres auditeurs.
• Extraire des données en masse ou voir des identifiants. Ces accès sont refusés même en lecture : l’export de données, les téléchargements de SBOM, l’export de facturation et les PDF de factures, les journaux CI bruts, les pages et l’API des webhooks, les pages des runners Forgejo Actions et l’API des jetons d’enregistrement de runner, ainsi que la page de suppression de l’organisation.

Si un auditeur a besoin de l’un de ces fichiers ou d’une modification, il le demande à un propriétaire. Un jeton d’API utilisé par un auditeur ne porte jamais qu’un accès en lecture.

Ajouter un auditeur

1. Nouvelle personne. Allez dans Administration de l’organisation → Membres (/<org>/_admin/members) → Inviter par e-mail → saisissez l’e-mail → dans Équipe(s), sélectionnez Auditors → Envoyer l’invitation.
2. Membre existant. frem.sh/org/<org>/teams → Auditors → Add team member.

Pour retirer un auditeur, retirez-le de l’équipe Auditors. Son accès aux paramètres d’administration prend fin dans les 5 minutes.

Une personne membre à la fois d’Auditors et d’Owners est propriétaire. Une personne membre à la fois d’Auditors et d’une équipe qui peut écrire (comme Members) conserve son accès en écriture au code et est auditeur en lecture seule sur les paramètres.

Utilisateurs facturables

• Les 5 premiers auditeurs d’une organisation sont gratuits.
• À partir du sixième, chaque auditeur est un utilisateur facturable, compté dans votre plafond d’utilisateurs comme n’importe quel autre. Lorsque le plafond est atteint, les règles habituelles s’appliquent.
• Un auditeur qui fait aussi partie d’une équipe pouvant écrire est déjà facturé à ce titre ; il ne coûte donc rien de plus et ne compte pas parmi les 5 auditeurs gratuits.
• La gratuité n’est pas réservée à des personnes précises : lorsque l’un des cinq premiers part, l’auditeur suivant devient gratuit.

Chaque lecture d’un auditeur est journalisée

Les lectures des paramètres d’administration par les propriétaires ne sont pas journalisées ; celles des auditeurs le sont. Chaque page ou point de terminaison d’API qu’un auditeur lit est enregistré dans le journal d’audit sous la forme d’un événement tenant.auditor.read, au plus une fois par auditeur et par point de terminaison toutes les 10 minutes. Les tentatives refusées sont journalisées à chaque fois.

Une équipe que vous aviez déjà appelée « Auditors »

Si votre organisation avait déjà, avant que fremforge n’introduise ce rôle, une équipe à vous nommée Auditors, fremforge n’y a pas touché. Elle reste une équipe ordinaire : ses membres n’ont pas accès aux paramètres d’administration, et elle est facturée comme toute autre équipe que vous avez créée.

Quand le plafond d’utilisateurs est atteint

Si votre organisation a atteint son plafond d’utilisateurs, un membre qui tente d’accéder à l’organisation voit une page « limite d’utilisateurs atteinte » à /<org>/seats-full au lieu de la ressource demandée. Depuis cette page, il peut envoyer en un clic une demande aux propriétaires de l’organisation pour ajouter un utilisateur.

Les propriétaires reçoivent cette demande (par e-mail et dans la cloche de notifications de l’administration) et peuvent ajouter un utilisateur depuis Administration de l’organisation → Facturation, ce qui lève le blocage pour le membre en attente. Le plafond d’utilisateurs doit être relevé pour que le membre puisse continuer ; d’ici là, son accès reste suspendu sur la page de limite atteinte.

Le plafond s’applique aussi aux membres que votre fournisseur d’identité ajoute par la synchronisation des groupes SSO : à la connexion, la synchronisation des groupes ne place personne dans une équipe avec accès en écriture une fois les utilisateurs payants de l’organisation épuisés (les équipes en lecture seule sont gratuites et toujours autorisées). Une modification du plafond ou du dépassement du nombre d’utilisateurs sur la page Facturation s’applique à la synchronisation des groupes dès que vous l’enregistrez. Il en va de même lorsque vous enregistrez une source SSO ou son association groupe→équipe, ce qui garantit que le plafond actuel est en place avant la prochaine connexion via cette source.

Changer les rôles

Le rôle d’un membre (propriétaire, membre ou lecteur) se change dans le produit, depuis le tiroir Gérer de la page Membres. Concrètement, le rôle correspond à l’appartenance à une équipe Forgejo : Owners = administration complète de l’organisation, Members = accès en lecture/écriture défini par les autorisations de dépôts de l’équipe, Viewers = lecture seule (et gratuit). Déplacer un membre uniquement dans Viewers le retire du nombre d’utilisateurs facturables au cycle de facturation suivant.

1. Allez dans Administration de l’organisation → Membres (/<org>/_admin/members).
2. Ouvrez le tiroir Gérer du membre.
3. Choisissez le nouveau rôle et confirmez. La modification d’équipe Forgejo correspondante est appliquée immédiatement.

Pour une composition d’équipe plus fine (équipes personnalisées, autorisations limitées à certains dépôts), utilisez la page native des équipes de Forgejo à frem.sh/org/<org>/teams. Les changements de rôle prennent effet immédiatement. Il n’y a ni délai de grâce ni e-mail de confirmation envoyé au membre.

Retirer un membre

1. Allez dans Administration de l’organisation → Membres (/<org>/_admin/members).
2. Ouvrez le tiroir Gérer du membre et choisissez Retirer.
3. Confirmez le retrait.

Ce qui se passe immédiatement :

• L’accès à tous les dépôts de l’organisation est révoqué.
• Toutes les sessions actives (navigateur ou API) de cet utilisateur sont invalidées.
• Le membre est retiré de toutes ses affectations d’équipe dans l’organisation.

Ce qui ne change pas :

• Les dépôts ne sont pas supprimés. Les dépôts appartiennent à l’organisation, pas aux membres individuels. Un membre qui possédait des dépôts dans l’organisation ne les emporte pas en partant.
• Les tickets, PR et commits restent attribués à son nom d’utilisateur. L’historique des contributions est préservé.
• Les PR et tickets ouverts qu’il a rédigés restent ouvertes et inchangées.

Le membre retiré sort du nombre d’utilisateurs facturables au cycle de facturation suivant. Aucun avoir n’est accordé pour la période en cours.

Liste de contrôle de départ

Lorsqu’un membre quitte l’organisation, parcourez cette liste avant de finaliser le retrait.

• Transférez la propriété des dépôts si le membre sur le départ possède directement des dépôts (vérifiez dans Administration de l’organisation → Dépôts les dépôts dont il est propriétaire). Transférez-les à l’organisation ou à un autre membre avant de le retirer.
• Faites tourner les secrets qu’il a pu connaître. Vérifiez quels secrets ont été créés ou mis à jour pour la dernière fois pendant qu’il y avait accès. Faites tourner ceux que son départ expose désormais.
• Révoquez les jetons d’API qu’il a créés. Allez dans Administration de l’organisation → Jetons d’API (/<org>/_admin/api-tokens) pour voir tous les jetons d’API de l’organisation. Révoquez tout jeton créé par le membre sur le départ.
• Vérifiez les jetons d’accès personnels (PAT). Les PAT sont liés au compte de l’utilisateur, pas à l’organisation. Une fois retiré de l’organisation, ses PAT ne peuvent plus accéder aux ressources de l’organisation. Mais si le membre sur le départ était propriétaire, vérifiez qu’aucun jeton aux portées élevées n’a été partagé avec des systèmes externes sous son nom.
• Passez en revue les intégrations et webhooks actifs. Si un webhook ou une intégration externe s’authentifie en tant que cet utilisateur, mettez-le à jour pour utiliser un jeton d’API de l’organisation ou un autre compte.

Déprovisionnement géré par SCIM

Si le provisionnement SCIM est configuré pour l’organisation, le cycle de vie des utilisateurs est géré par le fournisseur d’identité connecté (Okta, Entra ID, etc.). Désactiver ou supprimer un utilisateur dans le fournisseur d’identité le désactive automatiquement dans fremforge dans l’intervalle de synchronisation SCIM, généralement inférieur à cinq minutes.

Lorsqu’un utilisateur est désactivé via SCIM :

• Sa session fremforge est invalidée immédiatement.
• Il ne peut se connecter ni via le SSO ni avec un mot de passe local.
• Chaque identifiant fremforge qu’il détient cesse de fonctionner en une minute environ, et au plus en 10 minutes : sessions de la console, connexion de la CLI, jetons d’API qu’il a créés et ses connecteurs IA (MCP). Les sessions et jetons d’API sont refusés, pas supprimés, et fonctionnent de nouveau si la personne est réactivée. Ses autorisations de connecteurs IA sont révoquées. Un dev bench à lui en cours d’exécution est suspendu. Les sessions et jetons d’API sont refusés de la même façon lorsqu’un administrateur bloque la connexion d’une personne.
• Il est retiré du nombre d’utilisateurs facturables au cycle de facturation suivant.

Le retrait manuel via Administration de l’organisation → Membres n’est pas nécessaire lorsque SCIM est actif. Le fournisseur d’identité fait foi pour l’appartenance. Retirer un utilisateur dans fremforge sans le désactiver dans le fournisseur d’identité amènera SCIM à le provisionner de nouveau lors de la synchronisation suivante.

Voir Provisionnement SCIM pour les instructions de configuration.

Membres uniquement SSO

Un membre qui ne s’est jamais connecté que via le SSO n’a pas de mot de passe fremforge local. Son identité est entièrement contrôlée par le fournisseur d’identité.

Pour bloquer l’accès d’un membre uniquement SSO :

1. Révoquez son accès dans le fournisseur d’identité (désactivez le compte, retirez-le de l’affectation de l’application ou désactivez le SSO pour son compte).
2. Retirez-le éventuellement de l’organisation dans fremforge pour mettre à jour le nombre d’utilisateurs.

Révoquer l’accès dans le fournisseur d’identité suffit à empêcher la connexion. La session fremforge échouera lors du prochain contrôle de validation SSO. Si SCIM est activé, la désactivation dans le fournisseur d’identité déclenche aussi le déprovisionnement automatique, sans l’étape de retrait manuel de l’organisation.

Réinviter un ancien membre

Pour réinviter une personne précédemment retirée, envoyez-lui une nouvelle invitation depuis Administration de l’organisation → Membres → Inviter par e-mail, comme d’habitude.

Lorsqu’elle revient :

• Ses commits, tickets et PR antérieurs restent attribués à son nom d’utilisateur.
• L’accès aux dépôts est déterminé de nouveau par le rôle dans l’organisation et les éventuelles affectations de collaborateur au niveau des dépôts. Aucune configuration d’accès antérieure n’est restaurée automatiquement.

Si l’ancien membre a supprimé son compte fremforge après son départ, son nom d’utilisateur peut apparaître comme compte supprimé sur les contributions historiques. Si une autre personne a pris ce nom d’utilisateur entre-temps, l’attribution historique reflète le compte d’origine via l’identifiant utilisateur sous-jacent, et pas seulement la chaîne du nom d’utilisateur.

Permissions par dépôt

Les rôles au niveau de l’organisation déterminent l’accès de base. Pour un contrôle plus fin, vous pouvez ajouter des utilisateurs individuels comme collaborateurs sur des dépôts précis.

Ajouter un collaborateur :

1. Allez dans Dépôt → Paramètres → Collaborateurs.
2. Recherchez l’utilisateur par nom d’utilisateur ou par e-mail.
3. Choisissez un niveau de permission :

Les permissions de collaborateur s’ajoutent au rôle de l’utilisateur dans l’organisation, elles ne le remplacent pas — la plus élevée des deux s’applique. Un lecteur disposant d’un accès collaborateur Write sur un dépôt peut pousser vers ce dépôt. Un propriétaire ajouté comme collaborateur n’obtient rien de plus que ce que le rôle de propriétaire accorde déjà.

Les collaborateurs doivent être membres de votre organisation

Un collaborateur doit être membre de l’organisation propriétaire du dépôt. Vous ne pouvez pas rattacher une personne d’une autre organisation, ni ajouter directement un compte extérieur à un dépôt — invitez-la d’abord dans l’organisation (comme invité si elle n’a besoin que de lire), puis accordez-lui l’accès au dépôt.

Il s’agit d’un changement par rapport au comportement antérieur, où un administrateur de dépôt pouvait rattacher n’importe quel compte existant sur l’instance. Exiger l’appartenance garantit que toute personne ayant accès à votre code apparaît dans Administration de l’organisation → Membres, ce qui rend aussi complètes les revues d’accès et les procédures de départ.

Ce que coûte un collaborateur

Seule l’écriture est facturée :

Accorder l’écriture à une personne actuellement gratuite (un lecteur ou un invité) l’ajoute automatiquement à l’équipe canonique Collaborators, ce qui en fait un utilisateur payant. Vous n’avez pas à la déplacer à la main. Une personne déjà facturable — un membre, un propriétaire ou un collaborateur existant — n’est pas facturée deux fois.

Si cet utilisateur supplémentaire vous fait dépasser votre plafond :

• Avec le dépassement du nombre d’utilisateurs activé, l’autorisation réussit et l’utilisateur supplémentaire apparaît sur votre prochaine facture.
• Avec le dépassement du nombre d’utilisateurs désactivé, l’autorisation est refusée et vous êtes renvoyé vers Administration de l’organisation → Facturation → Utilisateurs. Désactiver le dépassement du nombre d’utilisateurs dans Administration de l’organisation → Facturation est la façon d’empêcher fremforge d’ajouter automatiquement des utilisateurs payants — le même interrupteur régit les invitations et les membres provisionnés par le SSO.

Retirer à quelqu’un son statut d’utilisateur facturable ne lui retire pas son accès d’un coup. Les autorisations d’écriture qui ne sont plus couvertes par un utilisateur facturable sont réduites à la lecture après un délai de grâce de 7 jours ; perdre ce statut transforme donc un collaborateur en l’équivalent d’un invité plutôt que de le bloquer. Rétablissez ce statut dans ce délai et rien ne change.

Via l’API REST

Le flux quotidien du cycle de vie des membres (inviter / lister / révoquer / retirer) est disponible sur l’API publique. Utilisez-la pour scripter l’intégration depuis un SIRH, automatiser les départs ou piloter les opérations depuis un agent IA.

• Lister les invitations GET /_app/api/v1/orgs/:slug/members/invitations?status=pending (portée seats:read)
• Inviter un membre POST /_app/api/v1/orgs/:slug/members/invitations corps : { "email": "...", "full_name": "...", "team_names": [...] } (portée seats:write)
• Révoquer une invitation en attente DELETE /_app/api/v1/orgs/:slug/members/invitations/:id (portée seats:write)
• Retirer un membre DELETE /_app/api/v1/orgs/:slug/members/:login (portée seats:write)
• Accorder / rejeter une réservation d’utilisateur POST /_app/api/v1/orgs/:slug/members/seat-holds/:id/grant ou .../dismiss (portée seats:write)

Nécessite un jeton d’accès personnel (PAT) avec la portée seats:write :

curl -X POST \
  -H "Authorization: Bearer ${FREMFORGE_PAT}" \
  -H "Content-Type: application/json" \
  -d '{"email":"new.hire@example.com","full_name":"New Hire","team_names":["engineering"]}' \
  https://frem.sh/_app/api/v1/orgs/acme/members/invitations

Consultez la référence de l’API REST publique pour la spécification OpenAPI complète.

Références croisées

• Provisionnement SCIM : cycle de vie automatisé des utilisateurs via Okta, Entra ID ou tout fournisseur d’identité conforme à SCIM 2.0
• SSO OIDC : configurez le SSO pour que les membres se connectent avec leur identité d’entreprise
• Facturation : comment les utilisateurs sont comptés et quand les membres retirés sortent du nombre d’utilisateurs facturables
• Administration de l’organisation : référence complète de l’administration de l’organisation
• API : gérez les membres par programmation via l’API REST