Skip to main content
POST
Create KYC Submission

How it works

You collect the user’s KYC data in your own UI and submit it with this endpoint. What happens next depends on how Ripio configured the KYC flow of your account, and the response tells you which case you are in through provider_url:
  • provider_url has a URL → the user still has to complete the identity verification. Redirect them to that URL: it is Ripio’s KYC platform, where the user uploads their ID document and completes the liveness check with the identity provider. Submitting the data through the API describes who collects the personal data beforehand; it does not replace the document and liveness steps.
  • provider_url is null → no further action is required from the user.

The flow

1

Get the KYC requirements

Call KYC Requirements to get the fields required for your account’s country.
2

Create the KYC Submission

Call this endpoint with the user’s email and the kyc_submission data. The response comes back with status: IN_REVIEW and, when your account’s flow requires it, a provider_url.
Response
3

Redirect the user to provider_url

Open provider_url in the user’s browser or in a webview. Once they finish the verification, they are sent back to the redirect_url you sent in the request — for example, a screen or deep link of your app for that user. If you don’t send one, the redirect URL configured for your account is used.
4

Get the result

The submission stays IN_REVIEW until the identity provider reports back. You get the outcome in two ways:
provider_url carries a token bound to this user’s verification process. Treat it as a secret: do not log it, share it or reuse it for another user.
A successful response does not mean the KYC is approved: it only means the verification was opened. The final status comes from the identity provider, after the user goes through provider_url.If the submission ends FAILED, you can create a new one for the same user. If the user already has an approved KYC, a new submission is rejected.

Authorizations

Authorization
string
header
required

B2B’s White Label API uses OAuth2. Currently there is only one supported authentication flow:

  • clientCredentials allows you to access your own B2B account (First-Party Integration) and performs transactions against the public API. This oauth2 flow is well suited for this API, as it allows machine-to-machine communication.

Every call to the API has to be authenticated with an OAuth2 Token. In order to request this token, you will need to have sandbox or production API Keys (client id and client secret) that will be needed to generate a credential in order to negotiate an ephemeral access token.

Every request must be accompianed by an Authorization header with a value that follows the following schema: Bearer ACCESS_TOKEN

Path Parameters

end_user_id
string
required

Body

application/json
email
string

End User's unique email.

kyc_submission
object

Json formatted data with the information detailed on KYC Requirements

redirect_url
string<uri>

Where the user is sent back after completing the verification on provider_url. Allowed schemes: https, worldapp, worldappstg. Optional: when omitted, the redirect URL configured for your account is used. If your account's flow needs one and neither is set, the request answers 400 with code 20092.

Maximum string length: 1000

Response

200 - application/json

OK

submission_id
string<uuid>

KYC Submission unique identifier

status
enum<string>

KYC Submission status.

Available options:
COMPLETED,
IN_REVIEW,
FAILED,
UPDATE_REQUIRED
provider_url
string | null

URL of Ripio's KYC platform, where the user completes the identity verification: ID document upload and liveness check with the identity provider. Redirect the user to it right after creating the KYC Submission. The URL carries a token for this verification process only: treat it as a secret and do not reuse it for another user. May be null if your account's KYC flow requires no further action from the user.

created_at
string<date-time>

ISO format creation datetime