Skip to main content
PATCH
Setting a status this way also permanently exempts the employee from the MVR payment gate (the same effect as PATCH /v2/mvr/employee/:employeeId/override) — if a real fund response later arrives for this employee, it only updates mvrStatus/mvrStatusReason for visibility and never blocks payment again. Fires the employee.mvr_status_changed webhook for any terminal status (VERIFIED, WARNING, REJECTED, NOT_SUPPORTED, TIMED_OUT) — never for PENDING, matching the real flow. Requires the employee to already have a fund identity (usi/smsf) set and a qualifying employer for the client — the same preconditions a real POST /v2/mvr/submit has, so the fabricated outcome stays realistic.
Note: this endpoint is not environment-restricted — it works in production too. Use it deliberately; it bypasses the real fund check entirely.

v1 is unaffected

You do not need to adopt the Employees v2 endpoints to use this, and v1 never forces MVR onto anything — keep using v1 for employees you don’t want MVR on at all, and opt specific employees into MVR (via v2, or this endpoint) whenever you’re ready to.

Request Parameters

string
required

Request Body

string (PENDING, VERIFIED, WARNING, REJECTED, TIMED_OUT, NOT_APPLICABLE, NOT_SUPPORTED, NOT_CHECKED)
required
The mvrStatus to force onto this employee. Setting this also permanently exempts the employee from the MVR payment gate — if a real fund response later arrives for this employee, it only updates mvrStatus/mvrStatusReason for visibility and never blocks payment.
string
Human-readable reason to store as mvrStatusReason, as if the fund had supplied it.
string
Optional explicit employerId override — see POST /v2/mvr/submit’s employerId.

Responses

Response fields

string
Synthetic transaction ID for the fabricated mvrRequest row — usable with GET /v2/mvr/:transactionId.
string
boolean
integer
string
Last modified on November 10, 2026