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.
