Submit verification data
First call in the KYC API flow. Nothing else is accepted before it: country is what routes the customer to their country’s requirements.
Answers 202, not 200. The request is validated before we answer; recording it upstream happens after. A 202 means accepted, not satisfied. Read the result from the kyc_updated webhook or GET /ramp/customer/{customer_id}/kyc?requirements=true.
Re-submitting overwrites what was sent before, and never moves the customer’s review status on its own. Personal accounts only.
Authorizations
API key sent in the Authorization header.
Path Parameters
The customer (child org) ID. Must belong to the caller's organization or a direct child.
Body
Personal data a partner submits on the customer's behalf.
YYYY-MM-DD. Any other format is a 400.
"1990-01-01"
The customer's tax identification number. The RFC for a Mexican customer.
"XAXX010101000"
The customer's country, as an ISO 3166-1 alpha-3 code. Alpha-2 codes and country names are rejected. This is the one country field for the customer (there is no separate nationality), and its value routes them to their country's requirements.
"MEX"
The customer's residential address. Required, and it must match the identity document you upload; the provider cross-checks the two.
Response
Accepted and being applied. The customer's current verification status is returned.
Where the customer's verification stands after a partner write. status is the same value GET /ramp/customer/{customer_id}/kyc reports, so there is one vocabulary across both.