For the complete documentation index, see llms.txt. You can also append .md to any page URL to get its markdown version.
Skip to main content
For the complete documentation index, see llms.txt.

For the complete documentation index, see llms.txt

Integrate ready-made onboarding flows

In this ready-made flow guide, you can learn how to implement ReuseID onboarding in your mobile app.

About ReuseID ready-made onboarding​

In a ReuseID onboarding flow, there are two required processes that need to be carried out with your app:

Identity proofing process​

For the identity proofing process, ReuseID ready-made onboarding supports ReadID and VideoID as identity proofing providers. This is set using the provider parameter in the request body.

You can find an overview of the differences between them in the table below:

Provider nameProvider valueDescription
VideoIDsignicatvideoidVideoID is one of Signicat's eIDV services for secure online customer onboarding.

It enables you to:
  • Capture a video recording of an ID document and/or the end-user's face.
  • Undertake actions to prove liveness, for example smiling at the camera.
ReadIDreadidReadID is one of Signicat's eIDV services for secure online customer onboarding.

The end-user identifies themselves using ReadID's NFC-supported solution to read their ID document.
Note

If you do not set an identity proofing process provider when you start onboarding, then ReuseID uses VideoID by default.

What does it look like?​

You can see what a ReuseID onboarding looks like in the sequence diagram below:

Sequence diagram showing a ReuseID onboarding

1. Start onboarding​

Before your app starts the MobileID registration, your server must start the ReuseID onboarding operation. To do this:

  1. Set the provider in the request body to choose the identity proofing provider:
Example: Start onboarding request body
{
  "externalRef": "000-000-000",
  "provider": "signicatvideoid",
  "videoidProviderOptions": {
    "docTypes": [138, 169, 147, 245, 277],
    "defaultId": 138
  }
}
  1. A response is returned to you. This contains the activationCode that your app uses to continue the MobileID registration.
Want to learn more?

To learn more about how the API works, see a complete walkthrough in our ReuseID Quick start guide.

2. MobileID device registration​

The next operation that you need to carry out is the MobileID registration.

To learn how to implement the registration process for Android and iOS, use the panel buttons below.

Terminology for registration

When you navigate our documentation, you will also see the term activation. In this context, both activation and registration are synonymous, and refer to the same operation.

Android
Learn how to implement the registration process for Android
iOS
Learn how to implement the registration process for iOS

Operation context​

For the complete documentation index, see llms.txt

Operation context is a MobileID feature that allows you to send data over an end-to-end encrypted channel between the backend and the mobile app.

In ReuseID, we use this feature to send data related to the ReuseID operation to the app.

Want to learn more?

To learn about how the operation context object is structured and how you can fetch the data, see our platform-specific documentation for Android and iOS.

Note

In the onboarding operation, we only use the post-operation context to share information.

Post-operation context​

Once the registration is complete, you will get a finishActivationResponse object. This object contains a post-operation context.

Response​

You can find an example of the response below:

Example: Post-operation context
{
  "post_operation_context" : {
    "context_content_b64": <signicatOperation>,
    "context_mime": "application/json"
  }
}
Response object description​

You can find a table of descriptions for the response object parameters below:

Signicat operation object​

The Signicat operation object (signicatOperation) is used to pass information related to the ReuseID process to the mobile app.

Object​

You can find examples of the object below:

Example: Signicat operation object for VideoID
{
  "signicatOperation": {
    "version": "1",
    "operation": "registration",
    "provider": "signicatvideoid",
    "token": <TOKEN>,
    "url": "https://etrust-sandbox.electronicid.eu/v2",
    "processType": "substantial",
    "processId": "8be8325a-9654-4165-a56f-0d1ccdc3bd3e",
    "videoidProviderOptions": {
      "docType": 1,
      "docTypes": [1, 2, 3],
      "defaultId": 1
    }
  }
}
Object description​

You can find a table of descriptions for the object parameters below:

VideoID provider options object​

The VideoID provider options object (videoidProviderOptions) contains VideoID provider-specific configuration options.

You can find a table of descriptions for the object parameters below:

Object description​

For the complete documentation index, see llms.txt

3. Perform identity proofing​

Once you have completed the MobileID registration, start the identity proofing process that matches the provider in the Signicat operation object.

VideoID as provider​

If the provider is signicatvideoid, then you need to start the VideoID process in your app. To do this:

1. VideoID authorisation​

Before starting the VideoID activity, you need to get an authorisation token for VideoID. You can do this by making a request to the videoid.request API:

  1. Obtain the following parameters from the Signicat operation object:
    • url
    • token
  2. Input this data into the following example:
    Example: Request to get VideoID authorisation token
    curl -X POST <URL>/videoid.request \
    -H 'Authorization: Bearer <TOKEN>' \
    -H 'content-type: application/json' \
    -d '{
        "process": "Unattended"
    }'
    What does unattended mean?

    In the SDK, the process that you are starting for VideoID is called Unattended. In other parts of the documentation, you will see us refer to this operation as Substantial.

  3. After a successful request , you will receive the following response:
    Example: Response with VideoID authorisation token
    {
    "id": "87a819bd-9419-417a-9e55-cab8789d4115",
    "authorization": "<authorisationToken>"
    }
    Note

    The authorization from this request is required in the next step when you start a VideoID activity.

2. Start VideoID activity​

For the complete documentation index, see llms.txt

Next, you need to start the VideoID activity in your app. You should consider the following when starting the activity:

Code examples​

Swift example
func makeUIViewController(context: Context) -> VideoIDSDK.VideoIDSDKViewController {
  let environment: VideoIDSDK.SDKEnvironment = VideoIDSDK.SDKEnvironment(
    url: <<url>>,
    authorization: <<token>>
  )
  let viewController = VideoIDSDKViewController(
    environment: environment,
    docType: <<DocType - Optional>>,
    docTypes: <<DocTypes - Optional>>,
    idDefault: <<DefaultId - Optional>>,
  )
  viewController.delegate = self
  return viewController
}

// Error Handling
func onComplete(videoID: String) {
  // VideoID process succeeded - Handle the next steps here
}
func onError(_ error: VideoIDError) {
  // VideoID process failed - Handle the error here
}
Want to customise VideoID further?

To learn more about VideoID and the available customisation options, you can navigate to the SDK documentation available in the ElectronicID dashboard.

ReadID as provider​

If the provider is readid, then you need to start the ReadID NFC scanning flow with the ReadID SDK.

The selected ReadID process is created by ReuseID, and your app should use the values returned in the Signicat operation object when continuing from MobileID registration to identity proofing.

When following the ReadID guide, map the ReuseID values to the ReadID SDK values as shown in the table below:

All values in this table are available in the Signicat operation object.

Want to learn more?

For platform-specific SDK setup and code examples, see the ReadID SaaS SDK integration guide.

On this page