📄️ 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.