Skip to main content
Verifying a party proves who they are. It does not cover the terms our banking and payment partners require that person to agree to. Those partners insist the real end customer reads and accepts their disclosures on a screen themselves — nobody may accept on their behalf. So there is one more step, and it belongs to your customer rather than to you: they visit a hosted page and accept each outstanding partner’s terms. You can let it surface as a gate after verification, or collect it up front before any of their data reaches a partner.
This is a gate, not an optional extra. A party cannot get a virtual bank account or receive a pay-out until its partner-terms consent is complete.

​
What you do

Three steps, and the middle one is not yours.
1

Read the consent state

GET /parties/{partyId}/partner-terms returns one status and, while acceptance is outstanding, the consentUrl.The status alone tells you whether a link must be presented. You never need to know which partners are involved or how many — it is one status and one link covering all of them.
2

Send your customer to the link

Present the consentUrl — a redirect, an email, wherever your flow puts it. They open it and accept.You cannot complete this step for them. That is the entire point of the requirement.
3

Wait for the status to advance

Once acceptance is recorded the status becomes ACCEPTED and the URL is no longer returned.Register a webhook rather than polling.
The party read carries the same state as a cached field, partnerTermsStatus on Get party details, if you would rather poll the party you are already fetching. The dedicated endpoint always returns the current link, so it is the one to use when you are about to show a link — a URL you stored earlier may have expired.
The flow above is reactive: you discover consent is needed when a party reaches the gate. You can also get ahead of it. POST /parties/{partyId}/partner-terms/link mints a link immediately, letting your customer accept every currently-enabled partner’s latest terms in one pass — before any of their data is sent to a partner. That is usually the better experience: consent is collected during your own onboarding rather than surfacing later as a blocker on a pay-out.
Each call supersedes the previous link for that party. A link you already handed out stops working. Never call it to check state — read the consent state for that.

​
What the page does

You do not build or host this page — Venly provides it and hands you the link. Two properties of it affect your flow:
  • One page for every outstanding partner. However many partners a party owes terms to, it is a single link and a single visit. Your customer is never bounced through one page per partner.
  • A separate acceptance per partner. There is no blanket accept-all, so a customer with several outstanding partners has several things to agree to before the page will let them finish. Expect the visit to take a moment rather than one click.
Each acceptance is recorded individually — who accepted, when, and which version of that partner’s terms they saw.
The terms themselves are not available over the API yet. Today the hosted page is the only place the disclosures are presented — you cannot retrieve their text or render them in your own interface. Exposing the terms and conditions through the API is planned for a later phase; until then, hand the customer the link.

​
It can come back

Consent is not once-and-forever. The requirement re-appears when:
  • a new partner is added for that party, or
  • an existing partner’s terms version changes.
When that happens the party returns to “acceptance required” with a refreshed link, and the page shows only what is newly outstanding — your customer does not re-accept what they already agreed to. Treat consent as a state you re-read, not a milestone you record once and forget. A party that was fully onboarded last month can legitimately need another visit.
Because the link expires, fetch it when you are about to show it. A consent URL stored at verification time and used days later will likely be stale.

​
When the platform is unreachable

The consent state is resolved at request time rather than stored, so the read can fail. It fails closed, deliberately: A 503 never means “nothing outstanding”. If the platform reports terms outstanding but no link, you get a 503 rather than a REQUIRED you cannot act on — so treating a failure as NOT_REQUIRED would skip the gate entirely.

​
What this changes for existing integrations

The consent state lives in its own field, partnerTermsStatus — it is not a new kycStatus value. Code that switches on kycStatus keeps working unchanged. What does change is the set of preconditions for money movement. If your integration creates virtual bank accounts or pay-outs, it needs to account for a verified party that is still not ready, and surface the consent link to the customer at that point.

​
Next steps

Onboarding lifecycle

Where consent sits among the other gates.

Account verification

KYC and KYB, and what they do and don’t cover.

Virtual bank accounts

One of the two flows consent gates.

Pay-outs

The other one.