SDK Integration

1. Signup and create a company profile

Signup and create an account in our dashboard page. There, under "Verification Flow Settings" will be able to get your company_app_id and other information and configuration options. You can also create more verification flows under "Company Settings".

2. Frontend: Add SDK on mobile with company app id

iOS: https://github.com/getsilt/ios-sdk

What happens next on Native Apps integration: On-click mobile sdk will open a webview using the company app id. Once verified the webview will close and return the silt_user_id and a company_app_token. You can see more info in the examples provided in the SDK code.

Here you can see a list of available query parameters.

Query param key	Value type	Description
company_app_id	String (Required)	Mandatory field to get the configuration of the company app. Create your company app now from the dashboard.getsilt.com. Ex: &company_app_id=c11d1782-bcdc-4854-b5c9-32fd160fba8b
customer_user_id	String (Recommended)	This can be your internal user id, the one in your database. This field can be useful to track which user got verified when you receive a webhook. You can also search by this field in the dashboard.getsilt.com. Ex: &customer_user_id=172345
user_email	String (Optional)	Used to prefill the email field in the signup screens. If the user already has a Silt account, he will be prompt to be able to skip taking pictures of the Id we already have. Ex: &user_email=steve@apple.com
meta	JSON (Optional)	You can use this field to store information a silt user that you will receive whenever a webhook is sent or in GET /status. Similar to customer_user_id, but without search option. Ex: &meta={"abc":"123", "grumpy_cat": "miao"} There is no need to encode the url.
redirect_url	String (Optional)	Important: Use this parameter as the last one of the url you generate. Url that will point the button in the verification complete screen. Ex: &redirect_url=https://YOURURL.com
hide_redirect_button	Boolean (Optional)	Used to hide the button of redirect in the verification complete screen. Some customers use it in the iframe integration. Ex: &hide_redirect_button=true
hide_manual_review	Boolean (Optional)	Not recomended. This option hides the option of sending a document to manual review. Ex: &hide_manual_review=true

3. Backend: Webhook to get notifications after user status update

When the status of a document of a user is created or updated, we can notify you to your Backend with a webhook pointing to the endpoint you provide us.

The body of the response of thw webhook will return the same response as /status request under user attribute, and the processing_attempt that triggered the webhook.

The most important check you must do is the user.status of the user object. This status may have the following possible FINAL values: SUCCESS | ERROR | MANUAL_REVIEW. On top of that, you will receive other status, like PENDING, but you can ignore them because you should receive another webhook with a final status. This user.status is computed based on the combination of status of all requirements you have set for that verification flow. If a user has a SUCCESS status in all verifications required by the verification flow, then the user will have a SUCCESS status. If a user has a MANUAL_REVIEW or ERROR status in any of the verifications required by the verification flow, then the user will have a MANUAL_REVIEW or ERROR status.

It is strongly recommended to use the parameter customer_user_id in the url of step 2. This way, you can know to which user of your database refers the notification.

You will receive all the verified information of the user in every webhook, inside user. What triggers the emission of the webhook, will be each processing attempt of a verification. That's why you will receive also the information of that processing attempt information, with its status. Possible values for processing_attempt.status are SUCCESS | ERROR | VERIFICATION_ERROR | PENDING | RUNNING | MANUAL_REVIEW. Keep in mind that if a manual verification takes place and status has MANUAL_REVIEW, you will have to check also the manual_review_status that may have the following possible values: SUCCESS | ERROR | PENDING

Some cases (less than 5%) require a manual verification. For obvious reasons, we cannot verify users instantly this way. We inform the user by email (if provided) once we have finished the verification, but you can also be notified once this happens. When you have changed the status of a document we will also make a POST request to the endpoint you provide us.