Vue d’ensemble

Répondre à une identité déclarée par l'identifiant publié de la personne — sans écrire le lien du demandeur.

Rapprochement d'identité 0.2.0

L’Entreprise soumet un LOT d’identités déclarées (le lot des salariés d’une signalétique) et reçoit un sort LIGNE À LIGNE, partiel par nature. Trois issues, et trois seulement : résolu-existant (une personne correspond sans ambiguïté, son identifiant publié est renvoyé), resolu-cree (aucune ne correspond, le domaine crée la personne et renvoie son identifiant neuf), rejete (plusieurs personnes candidates — aucune création, aucun choix par approximation ; la ligne est rejetée avec son motif ambiguite). Une ligne ambiguë ne crée jamais de personne ni de lien (INV-EP-14). Le demandeur ne reçoit qu’une issue par ligne : JAMAIS la liste des personnes candidates — l’issue rejete dit qu’il y a ambiguïté, pas qui la compose. Chaque ligne porte sa clé de rapprochement RH, du système de ressources humaines du client, qui joue deux rôles et deux seulement : corréler la réponse à la ligne soumise (l’Entreprise apparie sans réordonner) et rendre l’appel idempotent par cle_rapprochement_rh, dans le tenant de l’installation — deux soumissions de la même ligne ne créent pas deux personnes. Le domaine NE STOCKE PAS cette clé : elle transite pour la corrélation et l’idempotence. Le lot admet un sort partiel : un rejet n’invalide pas les résolutions du même lot.

La spécification intégrale — chaque opération avec sa description entière — se lit sur la page du contrat.

Information

• OpenAPI version: 3.1.0

Opérations

POST

/rapprochements-identite

Authentification

authentification

L’exigence : tout appel est authentifié (401) et autorisé par famille d’accès (403 hors famille) — l’opération déclare sa famille en portée, sous la forme epargnant:famille. La seule famille du domaine ouverte à une écriture est epargnant:rapprochement (restreinte — elle peut créer une personne). Le mécanisme est OIDC ; sa déclinaison relève de l’assemblage.

Security scheme type: http