An Entity is an end user (individual or business) of your product.
Endpoints in this section contain methods to create, verify, and get information about Entities.
Registration and validation of business entities has a very specific order of operations. We suggest reviewing the KYB (Know Your Business) section for an overview of the process.
All flows start with registering an individual or a business entity.
Before stating the ID Verification process you will need to call /check_handle to check the Sila Eco System to determine if a specific user_handle you want for your end user is NOT already taken.
Creates a new individual or business user and attaches KYC data and specified blockchain address to an assigned user handle.
This step does not start the KYC verification; it only adds the data to be verified.
Generating a specified blockchain/crypto address (wallet) is part of the /register endpoint.
See User Private Key & Wallet Public Key callout below.
*After registering a user, sometimes the user will have mistyped information and will then fail verification. Updating registered verification data can be done with the /update endpoints.
NOTE: Entity and Identity data cannot be updated after an identity verification has passed or while verification is still pending.
Starts KYC verification process on a registered user handle.
Returns whether entity attached to user handle is verified, not valid, or still pending.
If an end user gets back
documents_required it will be necessary to upload supporting documentation for an end user finish verifying their identity.*
Use the Triaging KYC Failures documentation to determine what documents are needed for each tag returned from the
Use can use the /document_types endpoint to return a list of supporting documentation types that you can filter and display to your end user.
IMPORTANT: Never share the reason an end user failed or the tags with the end user. You can only share what documents the end user needs to provide.
User Private Key & Wallet Public Key
Sila uses ECDSA to secure and validate requests. Learn more about that here.
If you are using a Sila Native SDK see "wallet generation" section for the public/private key pair function.
- wallet private key = user private key
- crypto_address (aka ETH Address or blockchain address) = public key
If you are building you own AUTH refer to the Authenticating with ECDSA docs.
Please NEVER share your private keys.
- Even test private keys used in the sandbox need to be kept a hidden.
- Remember to redact private keys and any other PII when sending code samples.
- Private Keys must be stored in an approved KMS
Sila Security Requirements can be reviewed here.
Updated 24 days ago