Skip to main content
A vendor that has just been created can receive nothing. They must first open their verification file and submit their documents and their payout destination. Yabetoo hosts this flow. You generate a link, you pass it to the vendor, they complete it.
The request body is empty.
201
No Idempotency-Key on this route, unlike vendor creation. The call resumes an in-progress session instead of opening a second one: you can replay it as many times as needed to regenerate the link of a vendor who lost theirs.

Refused fields

What the vendor does there

1

They open the link

The page is hosted by Yabetoo (verify.yabetoo.com). You can open it in a tab, send it by email, or embed it in an iframe.
2

They submit their documents

Identity document and selfie for level 1. Proof of address or trade register for level 2, which raises the limits.
3

They register their payout destination

This is their payout destination. The vendor submits it, not you, and that is why phone is refused when the account is created.
4

Yabetoo reviews the file

Automated verification where possible, human review otherwise.
There is no return_url. Connect v1 exposes no redirect parameter: the vendor finishes on a Yabetoo page. If you load the link in an iframe, the end of the flow is notified to you via postMessage. Otherwise, follow progress through webhooks or by querying the account.

During verification

This is deliberate: your vendor can sell from day one, but the money does not leave the system until their identity is established.
A consequence to know about. A vendor can accumulate funds and then have their file refused. Their funds are then refunded to the buyers, charge by charge. Do not promise an unverified vendor that their balance is theirs.

Following progress

Read the vendor’s compliance: the state of its file and what it is allowed to do.
200
  • verification.status follows the file: null until the vendor opens the link, then createddocuments_submittedin_reviewapproved (or rejected, needs_info).
  • capabilities.allowed_operations says what the vendor can do: withdraw only appears once the file is approved.
The status of GET /v1/connect/accounts/{acct} is the account’s (active from creation), not the file’s. To know whether a vendor is verified, read compliance.
No webhook is emitted when the file changes state: query this endpoint when you need it. Field details: API reference.

Errors

The 403 codes never distinguish “this vendor does not exist” from “this vendor is not yours”. That is intentional: otherwise the API would become a way to probe the existence of other people’s accounts.