Leden en teams

Rollen

Elk lid van een organisatie heeft precies één rol op organisatieniveau.

Een organisatie moet altijd minstens één Eigenaar hebben. Je kunt de laatste Eigenaar niet verwijderen of degraderen.

Hoe wordt bepaald of iemand een betalende gebruiker is?

Eén regel geldt voor alle bovenstaande rollen:

Je bent een betalende gebruiker als je ergens kunt schrijven. Is alles wat je hebt alleen-lezen, of heb je niets, dan ben je gratis. De enige uitzondering is het team Auditors: de eerste 5 leden met alleen leestoegang zijn gratis, en elk lid daarna is een betalende gebruiker.

Afgezien van Auditors bepaalt het recht dat je teams verlenen dit, niet hun naam. Een team met alleen leestoegang dat je zelf aanmaakt, is dus gratis, hoe breed of smal ook, en een team hernoemen verandert nooit wat je betaalt. Eigenaren, Leden en Medewerkers kunnen schrijven, dus zijn ze betalend; Lezers en Gasten kunnen dat niet, dus zijn ze het niet.

Leden uitnodigen

Ledenbeheer staat in de beheer-UI van fremforge op /<org>/_admin/members: de pagina Leden toont elk huidig lid met per lid een paneel Beheren, en bovenaan een formulier om mensen uit te nodigen. De eigen pagina van Forgejo, frem.sh/org/<org>/teams, blijft beschikbaar als terugvaloptie wanneer je teamrechten fijnmaziger wilt samenstellen; de pagina in het product dekt het dagelijkse uitnodigen, rollen wijzigen en verwijderen.

1. Ga naar Organisatiebeheer → Leden (/<org>/_admin/members).
2. Open Uitnodigen via e-mail.
3. Vul de gebruikersnaam of het e-mailadres van de genodigde in en kies een rol.
4. Klik op Uitnodiging versturen.

De genodigde krijgt een e-mail van noreply@frem.sh met een link om te accepteren. De link is 7 dagen geldig. Is hij verlopen, verstuur hem dan opnieuw vanuit het onderdeel Openstaande uitnodigingen op dezelfde pagina.

In het onderdeel Openstaande uitnodigingen staat de genodigde als In behandeling tot diegene accepteert. Leden die in behandeling zijn:

• Hebben geen toegang tot middelen van de organisatie.
• Tellen pas als betalende gebruiker zodra ze de uitnodiging accepteren.
• Kunnen op elk moment worden geannuleerd door ze uit het team te verwijderen zolang ze nog in behandeling zijn.

Zodra de genodigde accepteert, verandert de status in Actief en wordt diegene bij de volgende factuurcyclus meegeteld als betalende gebruiker. Activiteit is niet vereist; het accepteren telt.

Gratis lezers (alleen lezen, geen betalende gebruiker)

Een Lezer heeft alleen leestoegang tot de repository’s waartoe diegene toegang krijgt (klonen, code bekijken, issues en pull requests lezen), maar kan niet pushen, geen repository’s aanmaken en niet bij de beheerinstellingen van de organisatie. Lezers zijn gratis: ze tellen niet mee voor je gebruikerslimiet en worden nooit gefactureerd. Voeg er zoveel toe als je wilt: belanghebbenden, externen die alleen hoeven mee te kijken, dashboards met alleen leestoegang enzovoort. Iemand die ook de instellingen van je organisatie moet kunnen lezen, zoals een compliance-auditor, hoort in plaats daarvan in Auditors.

Technisch is een Lezer lid van het vaste team Viewers van de organisatie en van geen enkel team dat schrijftoegang geeft. Het tellen van gebruikers volgt het recht dat een team verleent, niet de naam: heb je alleen teams met leestoegang, dan ben je gratis; heb je ergens schrijftoegang, dan word je gefactureerd. (Voeg je iemand toe aan Viewers en Members, dan wordt diegene gefactureerd: schrijven wint.)

Omdat de regel op rechten is gebaseerd en niet op namen, is een team met alleen leestoegang dat je zelf aanmaakt (Stakeholders, Reviewers, hoe je het ook noemt) ook gratis, en dat verandert niet als je het tot een paar repository’s beperkt. Gebruik Guests als je precies dat wilt: gratis leestoegang tot gekozen repository’s. Het vaste team Auditors hoort daar niet bij: fremforge maakt het aan, het geeft toegang tot de organisatie-instellingen en niet alleen tot code, en alleen de eerste 5 leden zijn gratis (zie Auditors).

Een lezer toevoegen

Elk van deze manieren werkt; de weg via het product is het eenvoudigst:

1. Via de pagina Leden (aanbevolen). Ga naar Organisatiebeheer → Leden (/<org>/_admin/members) → Uitnodigen via e-mail → vul het e-mailadres in → kies onder Team(s) alleen Viewers → Uitnodiging versturen. Als diegene accepteert, komt diegene erbij als gratis lezer.
2. Een bestaand lid omzetten. Open het paneel Beheren van het lid en verplaats het naar Viewers (verwijder het uit Members/Owners). Bij de volgende factuurcyclus telt het lid niet meer als betalende gebruiker.
3. Automatisch via SSO. Koppel een groep uit je identiteitsprovider aan het team Viewers (zie SSO en SCIM). Iedereen in die groep wordt als gratis lezer ingericht, zonder uitnodiging per persoon.
4. Terugvaloptie in Forgejo. frem.sh/org/<org>/teams → Viewers → Teamlid toevoegen. Gebruik dit alleen als je teams fijnmaziger wilt samenstellen; de pagina Leden dekt het normale geval.

Gratis lezers worden in je facturatieoverzicht (Organisatiebeheer → Facturatie) en in de seats-API apart van betaalde gebruikers geteld, zodat je altijd ziet hoeveel gratis lezers je hebt tegenover hoeveel betalende gebruikers je gebruikt.

Niet hetzelfde als een lezer die alleen de documentatie ziet. Wil je iemand die je gepubliceerde documentatie kan lezen maar geen toegang tot repository’s en helemaal geen Forgejo-account heeft, voeg die persoon dan niet toe aan Viewers, maar geef de SSO-groep een lege koppeling van groep naar team. Zie Wiki en publieke documentatie. Een Lezer (team Viewers) krijgt wel een Forgejo-account en leestoegang tot de toegekende repository’s; een lezer die alleen de documentatie ziet niet.

Gasten (gratis lezen, specifieke repository’s)

Een Lezer kan elke repository in de organisatie lezen. Een Gast leest alleen de repository’s die jij kiest. Beide zijn gratis: code lezen kost nooit een betalende gebruiker, hoe breed of smal ook.

Gebruik Gasten voor een externe die één dienst beoordeelt, een auditor die twee repository’s nodig heeft in plaats van veertig, of een partnerteam dat je buiten al het andere wilt houden. Het is de versie van een Lezer met de minste rechten, en het kost hetzelfde: niets.

Gasten zitten in het vaste team Guests, dat in elke organisatie wordt aangemaakt en tot specifieke repository’s is beperkt in plaats van tot alle.

Een gast toevoegen

1. Ga naar Organisatiebeheer → Leden → Uitnodigen via e-mail → vul het e-mailadres in → kies onder Team(s) alleen Guests.
2. Kies welke repository’s het team Guests mag lezen: frem.sh/org/<org>/teams/guests → Repository’s → voeg de gewenste repository’s toe.
3. Verstuur de uitnodiging. Als diegene accepteert, kan diegene precies die repository’s lezen.

Wil je een bestaande gratis Lezer beperken tot specifieke repository’s, open dan het paneel Beheren en verplaats de persoon van Viewers naar Guests. Diegene blijft in beide gevallen gratis.

Guests en Collaborators worden door fremforge beheerd en kunnen niet worden verwijderd. Ze bepalen wat je betaalt: Guests houdt lezers met toegang tot specifieke repository’s gratis, Collaborators maakt van iemand die op specifieke repository’s schrijft een betalende gebruiker. Zou je een van beide verwijderen, dan veranderde de prijs van je organisatie ongemerkt, dus zijn beide vergrendeld, net als Members en Viewers. Je kunt vrij aanpassen welke repository’s elk team dekt en wie erin zit.

Auditors

Een Auditor kan alles in je organisatie bekijken en niets wijzigen. Gebruik deze rol voor een compliance- of beveiligingsauditor, een interne controlefunctie of iedereen die moet beoordelen hoe de organisatie is ingericht in plaats van alleen de code te lezen.

Elke organisatie heeft een vast team Auditors, aangemaakt en beheerd door fremforge. Het heeft leestoegang tot alle repository’s, en de leden kunnen ook de beheerinstellingen van de organisatie openen. Net als de andere vaste teams is het vergrendeld: je kunt het niet verwijderen, niet hernoemen en het niet meer dan leestoegang geven. Een eigenaar bepaalt wie erin zit.

Wat een auditor kan zien

• Elke repository, alleen-lezen, net als een Lezer: klonen, code bekijken, issues en pull requests lezen.
• De beheerinstellingen van de organisatie op /<org>/_admin/ en de overeenkomstige leesaanroepen in de REST API: beleid, beveiligingsinstellingen, SSO, leden, facturatie en het auditlog. Dat omvat wat een Eigenaar over personen ziet: op de pagina Leden de e-mailadressen, volledige namen, laatste aanmelding en MFA-status van leden, en bij de facturatie-instellingen de facturatiecontactpersoon en de ID’s van betaalmachtigingen.
• Instellingen van de organisatie en van repository’s in Forgejo (frem.sh/org/<org>/settings, de Instellingen van een repository), alleen-lezen.
• Compliancebewijs en attestaties. Een auditor kan ze ophalen; elke keer wordt dat vastgelegd in het auditlog.

Een banner op elke beheerpagina meldt dat je kijkt als auditor met alleen leestoegang. Knoppen en formulieren die iets zouden wijzigen, zijn uitgeschakeld.

Wat een auditor niet kan

• Iets wijzigen. Elk verzoek dat geen leesverzoek is, wordt geweigerd, op de beheerpagina’s, in de API en in Forgejo, voordat het het endpoint bereikt. In de API van fremforge is de weigering een 403 met de fout auditor-read-only. Een auditor kan geen leden toevoegen of verwijderen, ook geen andere auditors.
• Gegevens in bulk meenemen of inloggegevens zien. Deze worden zelfs als leesverzoek geweigerd: de gegevensexport, SBOM-downloads, de facturatie-export en pdf’s van facturen, ruwe CI-logs, de webhookpagina’s en de webhook-API, de runnerpagina’s van Forgejo Actions en de API voor registratietokens van runners, en de pagina om de organisatie te verwijderen.

Heeft een auditor een van die bestanden of een wijziging nodig, dan vraagt diegene het aan een eigenaar. Een API-token dat een auditor gebruikt, heeft altijd alleen leestoegang.

Een auditor toevoegen

1. Nieuwe persoon. Ga naar Organisatiebeheer → Leden (/<org>/_admin/members) → Uitnodigen via e-mail → vul het e-mailadres in → kies onder Team(s) Auditors → Uitnodiging versturen.
2. Bestaand lid. frem.sh/org/<org>/teams → Auditors → Teamlid toevoegen.

Om een auditor te verwijderen, haal je diegene uit het team Auditors. De toegang tot de beheerinstellingen stopt binnen 5 minuten.

Wie in Auditors en in Owners zit, is Eigenaar. Wie in Auditors zit en in een team met schrijftoegang (zoals Members), houdt schrijftoegang tot de code en is voor de instellingen een auditor met alleen leestoegang.

Betalende gebruikers

• De eerste 5 auditors in een organisatie zijn gratis.
• Een zesde of latere auditor is een betalende gebruiker en telt net als ieder ander mee voor je gebruikerslimiet. Is de limiet bereikt, dan gelden de gebruikelijke regels bij een volle gebruikerslimiet.
• Een auditor die ook in een team met schrijftoegang zit, is daardoor al een betalende gebruiker, kost dus niets extra en gebruikt geen van de 5 gratis plekken.
• De gratis plekken zijn niet voor bepaalde personen gereserveerd: vertrekt een van de eerste vijf, dan krijgt de volgende auditor de gratis plek.

Elke leesactie van een auditor wordt gelogd

Wanneer eigenaren de beheerinstellingen lezen, wordt dat niet gelogd; bij auditors wel. Elke pagina of elk API-endpoint dat een auditor leest, wordt vastgelegd in het auditlog als gebeurtenis tenant.auditor.read, hooguit één keer per auditor en endpoint per 10 minuten. Geweigerde pogingen worden elke keer gelogd.

Een team dat je al “Auditors” noemde

Had je organisatie al een eigen team met de naam Auditors voordat fremforge de rol invoerde, dan heeft fremforge dat ongemoeid gelaten. Het blijft een gewoon team: de leden krijgen geen toegang tot de beheerinstellingen, en het wordt geprijsd zoals elk ander team dat je hebt gemaakt.

Als de gebruikerslimiet bereikt is

Heeft je organisatie haar gebruikerslimiet bereikt, dan krijgt een lid dat de organisatie probeert te openen in plaats van het gevraagde de pagina “gebruikerslimiet bereikt” op /<org>/seats-full te zien. Vanaf die pagina kan diegene met één klik de eigenaren van de organisatie vragen een gebruiker toe te voegen.

Eigenaren ontvangen dat verzoek (per e-mail en via de meldingenbel in het beheer) en kunnen een gebruiker toevoegen via Organisatiebeheer → Facturatie, waarmee de blokkade voor het wachtende lid wordt opgeheven. Verhoog de gebruikerslimiet voordat het lid verder kan; tot dan blijft de toegang gepauzeerd op de pagina “gebruikerslimiet bereikt”.

De limiet geldt ook voor leden die je identiteitsprovider via SSO-groepssynchronisatie toevoegt: bij het inloggen plaatst de groepssynchronisatie niemand in een team met schrijftoegang zodra de betaalde gebruikers van de organisatie op zijn (teams met alleen leestoegang zijn gratis en altijd toegestaan). Een wijziging van de limiet of van de overschrijding van de gebruikerslimiet op de pagina Facturatie geldt voor groepssynchronisatie zodra je opslaat. Hetzelfde geldt voor het opslaan van een SSO-bron of de koppeling van groepen aan teams: dat zorgt ervoor dat de huidige limiet geldt vóór de volgende aanmelding via die bron.

Rollen wijzigen

De rol van een lid (Eigenaar, Lid of Lezer) wijzig je in het product via het paneel Beheren op de pagina Leden. Technisch komt de rol overeen met lidmaatschap van een Forgejo-team: Owners = volledig organisatiebeheer, Leden = lees- en schrijftoegang zoals bepaald door de repository-rechten van het team, Viewers = alleen lezen (en gratis). Zet je een lid alleen in Viewers, dan telt het vanaf de volgende factuurcyclus niet meer als betalende gebruiker.

1. Ga naar Organisatiebeheer → Leden (/<org>/_admin/members).
2. Open het paneel Beheren van het lid.
3. Kies de nieuwe rol en bevestig. De bijbehorende wijziging in het Forgejo-team wordt direct doorgevoerd.

Voor een fijnmaziger samenstelling van teams (eigen teams, rechten per repository) gebruik je de teampagina van Forgejo op frem.sh/org/<org>/teams. Rolwijzigingen gelden direct. Er is geen respijtperiode en het lid krijgt geen bevestigingsmail.

Een lid verwijderen

1. Ga naar Organisatiebeheer → Leden (/<org>/_admin/members).
2. Open het paneel Beheren van het lid en kies Verwijderen.
3. Bevestig het verwijderen.

Wat er direct gebeurt:

• De toegang tot alle repository’s van de organisatie wordt ingetrokken.
• Actieve sessies (browser of API) van die gebruiker worden ongeldig.
• Het lid wordt uit alle teams binnen de organisatie gehaald.

Wat niet verandert:

• Repository’s worden niet verwijderd. Repository’s zijn van de organisatie, niet van afzonderlijke leden. Een lid dat repository’s in de organisatie bezat, neemt die niet mee bij vertrek.
• Issues, PR’s en commits blijven toegeschreven aan de gebruikersnaam. De historische bijdragen blijven bewaard.
• Openstaande PR’s en issues die het lid heeft aangemaakt, blijven open en ongewijzigd.

Het verwijderde lid telt vanaf de volgende factuurcyclus niet meer als betalende gebruiker. Voor de lopende periode krijg je geen tegoed.

Checklist bij vertrek

Loop deze checklist door voordat je het verwijderen afrondt, als een lid de organisatie verlaat.

• Draag het eigenaarschap van repository’s over als het vertrekkende lid zelf repository’s bezit (kijk in Organisatiebeheer → Repository’s naar repository’s met diens gebruikersnaam als eigenaar). Draag ze over aan de organisatie of aan een ander lid voordat je het lid verwijdert.
• Roteer secrets die het lid gekend kan hebben. Kijk welke secrets zijn aangemaakt of voor het laatst bijgewerkt terwijl het lid toegang had. Roteer de secrets die door het vertrek nu blootgesteld zijn.
• Trek API-tokens in die het lid heeft aangemaakt. Ga naar Organisatiebeheer → API-tokens (/<org>/_admin/api-tokens) om alle API-tokens van de organisatie te zien. Trek elk token in dat het vertrekkende lid heeft aangemaakt.
• Controleer personal access tokens (PAT’s). PAT’s zijn gekoppeld aan het account van de gebruiker, niet aan de organisatie. Zodra iemand uit de organisatie is verwijderd, hebben diens PAT’s geen toegang meer tot middelen van de organisatie. Was het vertrekkende lid een Eigenaar, controleer dan dat er geen tokens met verhoogde scopes op diens naam met externe systemen zijn gedeeld.
• Controleer actieve integraties en webhooks. Authenticeert een webhook of externe integratie als deze gebruiker, zet die dan om naar een API-token van de organisatie of een ander account.

Deprovisioning via SCIM

Is SCIM-provisioning ingesteld voor de organisatie, dan beheert de gekoppelde IdP (Okta, Entra ID enzovoort) de levenscyclus van gebruikers. Een gebruiker deactiveren of verwijderen in de IdP deactiveert diegene automatisch in fremforge binnen het synchronisatie-interval van SCIM, meestal binnen vijf minuten.

Als een gebruiker via SCIM wordt gedeactiveerd:

• Wordt de fremforge-sessie direct ongeldig.
• Kan diegene niet meer inloggen via SSO of een lokaal wachtwoord.
• Werkt elk fremforge-inloggegeven van diegene binnen ongeveer een minuut, en uiterlijk binnen 10 minuten, niet meer: consolesessies, de aanmelding in de CLI, de API-tokens die diegene heeft aangemaakt en de AI-connectors (MCP). Sessies en API-tokens worden geweigerd, niet verwijderd, en werken weer als de persoon opnieuw wordt geactiveerd. De autorisaties van de AI-connectors worden ingetrokken. Een draaiende dev bench van diegene wordt opgeschort. Sessies en API-tokens worden op dezelfde manier geweigerd als een beheerder iemands aanmelding blokkeert.
• Telt diegene vanaf de volgende factuurcyclus niet meer als betalende gebruiker.

Handmatig verwijderen via Organisatiebeheer → Leden is niet nodig als SCIM actief is. De IdP is de bron van waarheid voor het lidmaatschap. Verwijder je een gebruiker in fremforge zonder diegene in de IdP te deactiveren, dan richt SCIM diegene bij de volgende synchronisatie opnieuw in.

Zie SCIM-provisioning voor de instructies om het in te stellen.

Leden die alleen via SSO inloggen

Een lid dat altijd alleen via SSO heeft ingelogd, heeft geen lokaal fremforge-wachtwoord. Diens identiteit wordt volledig door de IdP beheerd.

Zo blokkeer je de toegang van een lid dat alleen via SSO inlogt:

1. Trek de toegang in de IdP in (deactiveer het account, verwijder de app-toewijzing of schakel SSO uit voor het account).
2. Verwijder het lid desgewenst ook uit de organisatie in fremforge om het aantal gebruikers op te schonen.

Alleen de toegang in de IdP intrekken is genoeg om aanmelden te voorkomen. De fremforge-sessie mislukt bij de volgende SSO-validatie. Is SCIM ingeschakeld, dan leidt het deactiveren in de IdP ook tot automatische deprovisioning, zonder dat je het lid handmatig uit de organisatie hoeft te verwijderen.

Een voormalig lid opnieuw uitnodigen

Wil je iemand die eerder is verwijderd opnieuw uitnodigen, stuur dan zoals gewoonlijk een nieuwe uitnodiging via Organisatiebeheer → Leden → Uitnodigen via e-mail.

Als diegene terugkomt:

• Blijven eerdere commits, issues en PR’s toegeschreven aan de gebruikersnaam.
• Wordt de toegang tot repository’s opnieuw bepaald door de rol in de organisatie en eventuele toewijzingen als medewerker op repositoryniveau. Eerdere toegangsinstellingen worden niet automatisch hersteld.

Heeft het voormalige lid na vertrek het fremforge-account verwijderd, dan kan de gebruikersnaam bij historische bijdragen als verwijderd account worden weergegeven. Heeft intussen iemand anders die gebruikersnaam genomen, dan verwijst de historische toeschrijving via de onderliggende gebruikers-ID naar het oorspronkelijke account, niet alleen via de gebruikersnaam.

Rechten per repository

Rollen op organisatieniveau bepalen de basistoegang. Voor fijnmaziger controle kun je afzonderlijke gebruikers als medewerker aan specifieke repository’s toevoegen.

Een medewerker toevoegen:

1. Ga naar Repository → Instellingen → Medewerkers.
2. Zoek de gebruiker op gebruikersnaam of e-mailadres.
3. Kies een rechtenniveau:

Rechten als medewerker komen bovenop de rol van de gebruiker in de organisatie en vervangen die niet: het hoogste van de twee geldt. Een Lezer met Write-rechten als medewerker op een repository kan naar die repository pushen. Een Eigenaar krijgt als medewerker niets bij wat de rol Eigenaar al geeft.

Medewerkers moeten lid zijn van je organisatie

Een medewerker moet lid zijn van de organisatie die de repository bezit. Je kunt niemand uit een andere organisatie koppelen, en je kunt geen extern account rechtstreeks aan een repository toevoegen: nodig diegene eerst uit voor de organisatie (als Gast als leestoegang volstaat) en geef daarna toegang tot de repository.

Dit wijkt af van eerder gedrag, waarbij een beheerder van een repository elk bestaand account op de instantie kon koppelen. Doordat lidmaatschap vereist is, staat iedereen met toegang tot je code in Organisatiebeheer → Leden, en dat maakt toegangscontroles en vertrekprocedures ook volledig.

Wat een medewerker kost

Alleen schrijven kost een betalende gebruiker:

Geef je schrijfrechten aan iemand die nu gratis is (een Lezer of Gast), dan wordt diegene automatisch toegevoegd aan het vaste team Collaborators, waardoor diegene een betalende gebruiker wordt. Je hoeft de persoon niet handmatig te verplaatsen. Wie al betalend is (een Lid, een Eigenaar of een bestaande Medewerker), wordt niet dubbel gefactureerd.

Brengt die gebruiker je boven je gebruikerslimiet:

• Met overschrijding van de gebruikerslimiet ingeschakeld slaagt de toekenning en staat de extra gebruiker op je volgende factuur.
• Met overschrijding van de gebruikerslimiet uitgeschakeld wordt de toekenning geweigerd en word je naar Organisatiebeheer → Facturatie → Gebruikers verwezen. Overschrijding van de gebruikerslimiet uitzetten via Organisatiebeheer → Facturatie is de manier om te voorkomen dat fremforge automatisch betalende gebruikers toevoegt; dezelfde schakelaar geldt voor uitnodigingen en voor leden die via SSO worden ingericht.

Iemand als betalende gebruiker weghalen, haalt de toegang niet in één keer weg. Schrijfrechten die niet meer door een betalende gebruiker zijn gedekt, worden na een respijtperiode van 7 dagen teruggebracht tot lezen, dus een Medewerker die geen betalende gebruiker meer is, wordt het equivalent van een Gast in plaats van buitengesloten. Herstel je de betalende gebruiker binnen die periode, dan verandert er niets.

Via de REST API

Het dagelijkse beheer van de levenscyclus van leden (uitnodigen, opvragen, intrekken, verwijderen) is beschikbaar in de publieke API. Gebruik die als je onboarding vanuit een HR-systeem automatiseert, vertrek automatiseert of de handelingen door een AI-agent laat uitvoeren.

• Uitnodigingen opvragen GET /_app/api/v1/orgs/:slug/members/invitations?status=pending (scope seats:read)
• Een lid uitnodigen POST /_app/api/v1/orgs/:slug/members/invitations body: { "email": "...", "full_name": "...", "team_names": [...] } (scope seats:write)
• Een openstaande uitnodiging intrekken DELETE /_app/api/v1/orgs/:slug/members/invitations/:id (scope seats:write)
• Een lid verwijderen DELETE /_app/api/v1/orgs/:slug/members/:login (scope seats:write)
• Een wachtende gebruiker toelaten of afwijzen POST /_app/api/v1/orgs/:slug/members/seat-holds/:id/grant of .../dismiss (scope seats:write)

Hiervoor heb je een Personal Access Token (PAT) met de scope seats:write nodig:

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

Zie de referentie van de publieke REST API voor de volledige OpenAPI-specificatie.

Zie ook

• SCIM-provisioning: geautomatiseerde levenscyclus van gebruikers via Okta, Entra ID of elke IdP die SCIM 2.0 ondersteunt
• OIDC-SSO: stel SSO in zodat leden inloggen met hun zakelijke identiteit
• Facturatie: hoe betalende gebruikers worden geteld en wanneer verwijderde leden niet meer meetellen
• Organisatiebeheer: volledige referentie van de beheeromgeving van de organisatie
• API: leden programmatisch beheren via de REST API