📄️ Export a completed access review campaign's evidence
Returns the compliance evidence of a completed campaign, one row per decision in a stable order: who reviewed which access, the decision and its justification, delegations, and what was actually done about each revocation. Remediation fields come from the actions dispatched for the decision. Remediation is dispatched for first-level items on their final decision (`final_decision`, after every certification level), so a first-level row's `remediation_status` is `NOT_REQUIRED` (not revoked), `UNDECIDED` (the campaign closed with no decision), `NOT_STARTED` (revoked, nothing dispatched — remediated outside the platform, if at all), `PENDING`, `SUCCEEDED`, `FAILED`, or `PARTIAL` (some targets succeeded, some failed), and `remediation_actions` lists every attempt (latest attempt per target wins). A later level's row is `REVIEW_STEP`: its remediation is on the first-level row it reviewed. `ticket_reference` is the URL of the ticket the item's finding opened, if any. Page through with the cursor.
📄️ Export identity correlation decisions
Returns every decided identity correlation — accepted or rejected by a reviewer, linked or rejected by the matcher, or superseded — newest decision first, with the evidence it was decided on (confidence, similarity, compared attributes, reasoning) and who decided it. For eDiscovery and audit exports: page through with the cursor. A decision reflects the pair's current state: a matcher rejection that a settings change re-queues leaves this export until it is decided again. Link and unlink history, including changes made outside the review queue, is in `/ip/nhi/identity-change-audit`.
📄️ Identity change audit trail
Changes to which accounts belong to whom and to who owns what, newest first: canonical identity links and unlinks (by a person, a reviewer's decision, or the matcher merging groups), person links, canonical identity deletions, and entity ownership changes. Each entry is written in the same transaction as its change and names who made it (a person id, 'matcher', or 'system'). With `subject_id`, only the changes concerning that identity (a canonical identity, an account, an owned entity, or an owner). No total is reported.
📄️ Initiate helpdesk identity verification from an external integration
External-integration twin of PostHelpdeskVerifyInitiate. A push notification is sent to the target user's sensor (without the code); the operator reads the returned code aloud and the user types it into their app. A 404 means the subject has no active sensor — the integration should offer the email-OTP family as a fallback rather than treating it as a dead end.
📄️ Operator submits the caller's code (external integration)
External-integration twin of PostHelpdeskVerifySessionIDVerify. The operator enters the code the caller read aloud; it is verified server-side against the handshake session and marks the operator->caller direction done.
📄️ Get helpdesk verification status (external integration)
External-integration twin of GetHelpdeskVerifySessionIDStatus. Polled by the integration until the session reaches a terminal state. The session is scoped to the operator that initiated it, so the same operator must be asserted here.
📄️ Cancel a helpdesk verification session (external integration)
External-integration twin of PostHelpdeskVerifySessionIDCancel. Cancels an active session and notifies the target sensors.
📄️ Initiate email-OTP identity verification from an external integration
External-integration twin of PostHelpdeskVerifyEmailInitiate. Sends a one-time code to the identity's IdP-sourced verification email and returns a masked preview. This is a ONE-DIRECTIONAL control and therefore weaker than the sensor mTOTP flow: the caller proves themselves to the operator, but the operator proves nothing to the caller. Integrations must present it as a fallback, not as an equivalent option. Set `delegation_mode` + `delegate_email` to send the code to an approved delegate instead of the subject. Absent both, behaviour is unchanged.
📄️ Verify an email-OTP code (external integration)
External-integration twin of PostHelpdeskVerifyEmailVerify. Re-runs the IdP-sourced-email deny-gate before reporting success, so an identity removed from the verification source between initiate and verify cannot complete verification.
📄️ Cancel an outstanding email-OTP verification (external integration)
External-integration twin of PostHelpdeskVerifyEmailCancel. Discards an outstanding challenge before it is completed or expires.
📄️ List eligible delegates for delegated verification (external integration)
External-integration twin of GetHelpdeskVerifyDelegateCandidates. Returns the delegates the operator may pick for a given subject and mode. global_approved → approved-list members eligible for the chosen verification_method; line_manager → the subject's line manager (HRIS graph); unconstrained → empty. For `unconstrained` the integration should collect the delegate email as free text: enumerating every user is intentionally unsupported, and the console fills that case from a sensor-authenticated peer search that is not reachable from an integration. Note that under `unconstrained` the delegate-initiate call validates only that the delegate is reachable (has an active sensor / is present in the verification source), not that they are on any eligibility list — which is what the mode means.
📄️ Initiate delegated identity verification from an external integration
External-integration twin of PostHelpdeskVerifyDelegateInitiate. The operator verifies a subject who has no device by exchanging codes with an approved delegate. Rides the same handshake infrastructure, so status, code submission and cancellation reuse the external helpdesk-verify {session_id} endpoints. A 404 means the delegate has no active sensor — the same meaning the non-delegated external initiate carries, so the integration can offer a fallback rather than treating it as a dead end.
📄️ List identity-verification candidates (external integration)
External-integration twin of GetSensorsVerificationCandidates. The integration filters by the caller's email address to learn the subject's identity id and which verification methods are available to them, then calls the matching initiate endpoint. An empty result is a displayable helpdesk answer ('this caller cannot be verified'), not an error. Note that a caller belonging to a connection other than the configured one also reads as empty — a misconfiguration, so validate `connection_id` at install time.