1. List the current team and follow the collection's returned pagination metadata.
2. Create the intended user with a valid email and optional display_name. The default initial state is invited.
3. Store the returned user public ID. Apply permitted status or display-name changes through that user's PATCH resource, with a current If-Match version where supported.
4. Assign roles by PUTing the complete role_ids list. The supplied roles must be accessible to your tenant.
5. When a staff member leaves, review their assignments and remove the module team record through the supported DELETE operation if appropriate.

No. A stored invited record is not delivery evidence. Verify the actual account invitation or onboarding workflow separately before telling the staff member to expect access. Similarly, mfa_required is a stored policy flag; it is not proof that a user has enrolled or completed a live MFA challenge.

It replaces assignments. Include every role that should remain. An empty list removes the role assignments rather than leaving them unchanged. Compare the user's effective access after a change and retain only the permissions required for their work.

No. The operation affects the module's team record. Account closure, billing ownership and other WHMCS user relationships have separate administrative workflows.

Keep a useful change record with the staff identity, role decision and request reference. Use idempotency for mutations and re-read after version conflicts so an automated staff synchroniser does not overwrite a later access decision.

• Diagnose API permission errors using the profile and capability endpoints
• Create and administer a reseller account with the correct commercial scope
• Read account audit events and mark notifications as read
• Get started with the current Nabtech Domain Nexus v2 API