Provisioning utilisateurs

L'API de provisioning utilisateurs permet d'automatiser l'onboarding et l'offboarding des membres d'un tenant Architecture Platform depuis votre IdM, votre outil RH ou un script CI.

Tous les endpoints ci-dessous nécessitent un PAT dont le porteur a le rôle tenant-admin sur le tenant cible. Un PAT créé par un architect ou un contributor recevra un 403.

Base URL

https://api.arch-platform.com/api/v1/tenant/invitations

Endpoints

Method	Path	Scope	Description
`POST`	`/`	`write`	Invite un membre par email avec un rôle ARB
`GET`	`/`	`read`	Liste toutes les invitations (tous statuts)
`GET`	`/members`	`read`	Liste les membres actifs et leurs rôles
`DELETE`	`/{id}`	`write`	Révoque une invitation `PENDING`
`DELETE`	`/members/{userSub}`	`write`	Retire l'accès d'un membre déjà accepté

Inviter un membre

Choisissez le rôle ARB. Valeurs acceptées : tenant-admin, architect, portfolio-manager, contributor, viewer, arb-member.

Envoyez l'invitation. Un email avec un magic-link (TTL 7 jours) part vers le destinataire. Le compte Keycloak est créé à l'acceptation, pas avant.

L'invité accepte en cliquant sur le lien et en définissant son mot de passe. Son rôle ARB est appliqué immédiatement.

Requête

curl -X POST https://api.arch-platform.com/api/v1/tenant/invitations \
  -H "Authorization: Bearer arc_pat_xxx" \
  -H "Content-Type: application/json" \
  -d '{
    "email": "jane.doe@acme.com",
    "arbRole": "architect"
  }'

Réponse `201 Created`

{
  "id": "5f3a8c2e-9b1d-4e7a-a8f4-1c2d3e4f5a6b",
  "email": "jane.doe@acme.com",
  "arbRole": "architect",
  "status": "PENDING",
  "invitedByEmail": "admin@acme.com",
  "expiresAt": "2026-06-30T10:00:00Z",
  "createdAt": "2026-06-23T10:00:00Z",
  "acceptedAt": null,
  "revokedAt": null
}

Erreurs possibles

Statut	`errorCode`	Cause
`400`	`INVALID_INVITATION_PARAM`	Rôle non assignable, email mal formé, déjà membre
`403`	Insufficient scope	PAT scope ≠ `write` ou porteur sans `tenant-admin`
`409`	Conflict	Une invitation `PENDING` existe déjà pour cet email

Lister les membres actifs

curl https://api.arch-platform.com/api/v1/tenant/invitations/members \
  -H "Authorization: Bearer arc_pat_xxx"

Réponse `200 OK`

[
  {
    "userSub": "kc-uuid-1234",
    "userEmail": "alice@acme.com",
    "arbRole": "tenant-admin",
    "source": "SIGNUP",
    "grantedAt": "2026-01-15T09:30:00Z"
  },
  {
    "userSub": "kc-uuid-5678",
    "userEmail": "bob@acme.com",
    "arbRole": "architect",
    "source": "INVITATION",
    "grantedAt": "2026-03-22T14:12:00Z"
  }
]

Le champ source distingue la provenance du grant : SIGNUP (premier inscrit, devient tenant-admin), INVITATION (acceptée), SSO_JIT (JIT-provisioning OIDC).

Action irréversible. Le membre perd immédiatement l'accès au tenant, mais son compte Keycloak global subsiste (il peut être ré-invité plus tard). Les notices/sessions qu'il a créées restent attribuées à son userSub (audit trail préservé).

curl -X DELETE \
  https://api.arch-platform.com/api/v1/tenant/invitations/members/kc-uuid-5678 \
  -H "Authorization: Bearer arc_pat_xxx"

Réponse 204 No Content si succès, 404 si le userSub n'existe pas dans le tenant (anti-IDOR : on ne révèle pas l'existence d'un user chez un autre tenant).

Script d'offboarding RH (exemple Python)

import requests, csv, os

PAT = os.environ["ARCH_PAT"]
BASE = "https://api.arch-platform.com/api/v1/tenant/invitations"
HEADERS = {"Authorization": f"Bearer {PAT}"}

# 1. Récupère la liste des membres actifs
members = requests.get(f"{BASE}/members", headers=HEADERS).json()
emails_to_remove = {row["email"] for row in csv.DictReader(open("leavers.csv"))}

# 2. Révoque ceux dont l'email matche les sortants RH
for m in members:
    if m["userEmail"] in emails_to_remove:
        r = requests.delete(f"{BASE}/members/{m['userSub']}", headers=HEADERS)
        print(f"{m['userEmail']} → {r.status_code}")