SDK Integration

1. Email us: Get your company app Id

Request your company_app_id to the Silt Team at the email address customers@getsilt.com. This Id is unique for you, and it will be the same that the one required in the API integration flow.

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 (Optional)	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)	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. Store silt_user_id

3.1. Frontend: Send silt_user_id to your BE

Make the POST request to your own backend described in step 4. This request requires as parameters silt_user_id & company_app_token.

3.2. Backend: Create an endpoint to receive silt_user_id from your FE

Create a backend endpoint to receive the silt_user_id and company_app_token (as described in step 3). After receiving this, you have the data required to ask the info of that user to Silt's backend as described in step 4.

Store silt_user_id to your database so you can easily reference the verification status at any time.

4. Backend: Check user's verification status to Silt

Use company_app_token against Silt's backend to the endpoint

GET https://api.siltapp.com/v1/users/{silt_user_id}/status/

Auth Header
Use a Bearer Header:
Authorization: Bearer {access_token}
or Temporary-Token Header:
X-Company-App-Temporary-Token: {company_app_token}
or X-Company-App-API-Token Header:
X-Company-App-API-Token: {company_app_api_token}

Don't forget that you should still use the X-Company-App-Id Header.

Check status: SUCCESS | MANUAL_REVIEW | PENDING | ERROR to know if a user is verified or not. Use the national_id | passport | driving_license objects to retreive the data extracted from the documents.

You are not required to store any of these, just what suits you best.

5. (Optional, for better UX) 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.

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 once we have finished the verification verification, but you can also be notified once this happens. When you have changed the status of a document we will make a POST request to the endpoint you provide us. The response will return the same response as /status request under user field, the processing_attempt that triggered the webhook, its status.