ZFA first-line verification of a POP
POST/referrals/:referralId/proof-of-payment/:popId/verify
ZFA staff reviews the uploaded evidence and confirms the POP is legible and the amount matches. This is the first of two verification stages — the referral remains in premium_payment_pending until the insurer also confirms.
Request
Responses
- 200
- 201
- 400
- 401
- 403
- 404
- 409
- 422
- 429
- 500
POP moved to zfa_verified.
Resource created. Body follows the shared { data, meta } envelope; data is the newly-created resource.
The request payload failed validation. error.details lists the offending fields with human-readable messages and the class-validator constraint that fired. Fix the payload and retry — this is not a transient failure.
Missing, malformed, or expired authentication token. Log in via POST /auth/login (or refresh via POST /auth/refresh) and retry with a fresh Authorization: Bearer <accessToken> header.
The authenticated caller does not carry the required permission or is scoped out of this resource by the object-authorization service (e.g. an agent trying to view another agent's referrals). Grant the missing permission via a role change or scope the query to resources the caller owns.
The referenced resource does not exist or is not visible to the caller. Note: object-level scoping is opaque — a resource you cannot see is indistinguishable from a resource that does not exist.
POP is not in pending_zfa_review state.
The request is syntactically valid but violates a business invariant — a referral state transition not permitted from the current status, a wallet withdrawal exceeding the available balance, or a POP being confirmed before it has been ZFA-verified. error.code is one of INVALID_TRANSITION, INVARIANT_VIOLATION, or a domain-specific value; error.message explains the invariant.
Rate limit exceeded. Global default is 120 requests/minute per IP; auth-flow, OTP, self-registration, WebAuthn, IRA lookup, and public-lead endpoints carry tighter per-endpoint limits. Retry after the delay indicated by the Retry-After header.
Response Headers
Seconds to wait before retrying.
Unhandled server error. The response carries a meta.requestId correlator you can hand to platform operations to trace the failure through structured logs and the hash-chained audit trail. Retry with the same Idempotency-Key header if the endpoint accepts idempotency.