409 partner-onboarding-pending. It is now a readable — and
startable — resource of its own.
The three gates, side by side
They are independent. A party can be
VERIFIED, have ACCEPTED the terms, and still be PENDING
here.
Reading the status
Response (200)
Reading never triggers anything. The same value is cached on the party as
partnerOnboardingStatus,
so a plain Get a party shows it too.
Starting it early
Rather than letting the first virtual-bank-account call kick onboarding off and fail, start it as soon as the party is verified:202 with the current status, normally PENDING — and
idempotent while onboarding is PENDING or APPROVED. Poll the read endpoint for the outcome.
Provisioning a virtual bank account after APPROVED then succeeds first time.
REJECTED is not a dead end. Calling POST again re-attempts onboarding, so if the underlying reason
has been resolved — corrected details, a re-run verification — you can retry without involving Venly.Preconditions
The request is refused with a retryable409 until the party qualifies:
And with a terminal
400 party-type-not-supported if the party is an ORGANISATION: partner
onboarding is individual-scoped.
Where it fits in the flow
Front-load all three while your customer is still in your onboarding UI. Verification and consent need the customer present; partner onboarding does not, so start it the moment verification clears and it will usually beAPPROVED before the customer asks for bank details.
Next steps
Partner-terms consent
The gate that comes just before this one.
Virtual bank accounts
The first thing partner onboarding unblocks.
Troubleshooting verification
The retryable / terminal split across every onboarding error.
Onboarding lifecycle
All the states, from a new party to an account that can move money.

