/get_verifications
Advanced KYC endpoint that returns the full list of verification records for a single user_handle.
This doc has been updated with Priority specifications.
Advanced KYC ONLY
If you're using legacy Classic KYC, use /check_kyc.
Takes a single user_handle and returns a list of verification records with some associated data, including verification_uuid and verification_status.
Use this endpoint to retrieve verification_uuid for an entity if needed. Use /get_verifications/<verification_uuid> for further details on a single verification record, including reasons strings.
Request
Authorization / Authentication
Apps using Access Token Authorization
Use a valid access token in an Authorization: Bearer request header.
See Auth Token Overview for more details.
NOTE: Though we recommend using JWT, you can use this endpoint with ECDSA.
POST /0.2/get_verifications HTTP/1.1
sandbox.silamoney.com
Content-Type: application/json
Authorization: Bearer [GENERATED JWT TOKEN HERE]
{
"header": {
"created": 1234567890, //required
"app_handle": "your_app_handle", //required
"user_handle":"you_user_handle", //required
"version": "0.2",
"reference": "<your unique id>"
}
}
***
HTTP/1.1 200 OK
{
"success": True,
"reference": "<your unique id>",
"sila_reference_id": "sila_assigned_id",
"verifications": [{
"verification_uuid": "<uuid>",
"flow": "<uuid of KYC Flow>",
"verification_status": "<name of verification status>",
"requested_at": "<timestamp of /kyc call>"
}]
}
Request Attributes
| Key | Type | Description |
|---|---|---|
| header | JSON object | Required. Required keys: created - Unix epoch timestamp in seconds. Must not be future-dated and must not be dated more than 5 minutes in the past.app_handle - your app handleuser_handle - the user_handle to pull verification data for.Optional keys: reference: Can be any value for your own reference. If not provided, one will be assigned.version: Cannot be null if key is present. Valid values: 0.2, v0.2, V0.2 |
Verification Statuses
| Verification Status | Description |
|---|---|
| 'unverified' | Entity has not had a KYC evaluation |
| 'passed' | Entity has passed KYC |
| 'pending' | An entity's KYC evaluation is in progress |
| 'review' | Under manual review by Sila and/or Priority |
| 'failed' | Entity has failed KYC |
| 'member_failed' | Business member failed KYC. |
| 'member_review' | Happens when a business member is under manual review. Documents may or may not be required for verification |
| 'member_pending' | A business member's KYC evaluation is in progress |
| 'documents_required' | Documents required to continue verification process |
| 'documents_received' | Documents were received and are being reviewed |
If verification_status is documents_required
documents_requiredAutomatic failure after 30 days
If you have an end user that has remained in a
documents_requiredstatus for 30 days, they will automatically fail KYC.You can confirm the failure is due to expiration by checking for
LEAD TIME EXPIREDreturned as a reason by /get_verification/verification_uuid.If you have an end user in this scenario, proceed by calling /kyc again. This will create a new verification record with a new verification_uuid to upload docs to. The original record will remain in failed.
This means that further verification is required to pass this end user through KYC successfully, and documents need to be uploaded via /documents.
- Use the
reasonsprovided by /get_verifications/<verification_uuid> to determine the type of doc to upload, then use /documents to upload any necessary docs. You can find a mapping laid out in our docs here.reasonsare returned as an array of strings. A few examples include:Unable to verify business name, address, TIN and phone on business recordsUnable to verify SSN/TINUnable to verify date-of-birth
- There are approximately 130 possible reason strings. We have that full list mapped to the type of verification needed available upon request.
- If a verification record goes to
documents_requiredand documents are not uploaded within 30 days, that verification record will automatically expire and verification status will transition tofailed.- You can confirm the failure is due to expiration by checking for
LEAD TIME EXPIREDreturned as a reason by /get_verification/verification_uuid. - If you have an end user in this scenario, proceed by calling /kyc again. This will create a new verification record with a new verification_uuid to upload docs to. The original record will remain in
failed.
- You can confirm the failure is due to expiration by checking for
- Not a requirement, but you may consider reviewing the PII provided for the entity during /register and updating anything that may be incorrect.
- If the doc is incomplete in some way, such as missing a signature, you will be prompted to upload the doc again.
- If the doc provided does not provide enough further verification to pass KYC, you will be prompted to upload a different doc.
- Priority estimates an approximately 24 hour turnaround time for reviewing uploaded docs.
- There is NOT a limit on the number of times the same or different docs can be uploaded for a single verification record, but each entity is limited to a single verification record. If an entity has already begun the KYC process, you will receive an error if you call /kyc again.
Responses
| Status Code | Success Attribute | Description |
|---|---|---|
| 200 | true | |
| 403 | false | The requested user_handle is not mapped to the app requested. |
Updated about 1 month ago
