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

Migrate from MobileID to ReuseID

Our ReuseID API is the next-generation API for reusable identity services, representing the future of our platform.

It offers a broader set of functionalities than the first-generation MobileID API, such as authentication with both MobileID and Passkeys.

About the migration​

We have moved MobileID authentication under ReuseID. This means that you can now use the ReuseID API to:

  • Create and manage users.
  • Create and manage MobileID devices.
  • Perform MobileID device operations.

The underlying data and MobileID features are the same, which means that there is no impact for your end-users.

The migration is a technical change to transition your integration from MobileID API endpoints to ReuseID API endpoints.

MobileID API customers only

This migration guide is only relevant for existing MobileID customers who have integrated using the MobileID API.

If you are building a new integration, then this guide does not apply to you. Instead, you should navigate directly to the ReuseID API reference documentation.

Why migrate to ReuseID?​

We are moving MobileID devices under ReuseID to make MobileID part of a broader reusable identity platform. With ReuseID, you can create one trusted user, then reuse that identity across services, channels, and operations.

By migrating to ReuseID, you benefit from:

BenefitDescription
Access to future capabilitiesReuseID is the next-generation API for reusable identity services. All future improvements and new features will be added to the ReuseID API, not the MobileID API.
A multi-credential user modelMobileID devices are now credentials on the ReuseID user. This makes it easier to combine MobileID with other credential types, such as passkeys.
Works in parallel

MobileID and ReuseID use the same backend data for users and MobileID devices. This means that you can migrate incrementally, running both the MobileID API and ReuseID API in parallel.

Summary of changes​

The following table shows a summary of the changes that you need to make in your integration to migrate from the MobileID API to the ReuseID API:

ElementChange
Base URLThe base URL changes from /mobileid/core to /reuseid/core.
UsersThe MobileID users are now called ReuseID users.
DevicesMobileID devices are represented as ReuseID credentials, with type DEVICE.
Device operationsDevice-specific operations are moved under the /credentials/devices/ path.
ResponsesSome responses are simplified or renamed to support multiple credential types.
API client permissionsYou must update your API client permissions in the Signicat Dashboard.
Event subscriptionsYou must update your event subscriptions in the Signicat Dashboard.

1. Signicat Dashboard configuration​

Before you begin the API migration, ensure you configure the following settings for your account in the Signicat Dashboard:

API client permissions​

To use the ReuseID API with MobileID authentication, you need to update your API client permissions in the Signicat Dashboard. To do this:

  1. Go to Signicat Dashboard > Settings > API clients.
  2. From the list, find the API client that your integration uses, then click the Edit button to the right-hand side of it.
  3. Click the Permissions tab.
  4. Click the + Manage product access button.
  5. Navigate to the ReuseID section, then tick the permission for ReuseID MobileID Device API.

    Screenshot showing the ReuseID MobileID Device API permission in the Signicat Dashboard

  6. To save your changes, click the Update button at the bottom of the page.

Event subscriptions​

If your integration receives operation results through events, then you need to update your event subscriptions for ReuseID in the Signicat Dashboard.

To do this:

  1. Go to Signicat Dashboard > Settings > Events.
  2. To view your subscriptions, click Subscriptions in the left-side menu.
  3. From the list, find the subscription that your integration uses for MobileID events, then click the Details button to the right-hand side of it.
    Note

    Alternatively, you can also create a new subscription. To do this, click the + Add subscription button at the top of the page.

  4. Navigate to the Listen to section, then expand the ReuseID dropdown to show all ReuseID events.
  5. Tick the ReuseID events that match the MobileID events you already subscribe to.

    Screenshot showing ReuseID events that can be selected for an event subscription in the Signicat Dashboard

  6. To save your changes, click the Update button at the bottom of the page.
Our recommendation

We recommend that you keep both MobileID and ReuseID events selected during the migration transition period.

This allows your system to receive events from both services until all relevant calls have moved to the ReuseID API.

2. API integration configuration​

Next, you need to configure your API integration to use the Reuse API instead. You can use the sections below as a reference for the changes you need to make:

Base URL​

You need to update the base URL to point to the ReuseID API instead of the MobileID API:

Base URL
https://api.signicat.com/mobileid/core

User operations​

You can find a summary of changes for user operations in the sections below.

Get transactions for user​

Transactions now support multiple credential types in ReuseID, which can be either MobileID devices or passkeys.

For an overview of the changes to this operation, see the table below:

Get devices​

The MobileID operation for listing an end-user's devices has been generalised in ReuseID, so that it returns paginated credentials for a user.

The path for this operation is:

Get devices
GET /devices
Want to learn more?

To learn more, see the Get devices endpoint in our MobileID API reference documentation.

For an overview of the changes to this operation, use the table below:

Get identity verifications for user​

This is a new ReuseID operation that returns a list of all identity verifications that a ReuseID user has carried out.

The path for this operation is:

Get identity verifications for user
GET /users/{userId}/id-verifications
Want to learn more?

To learn more, see the Get identity verifications for user endpoint in our ReuseID API reference documentation.

MobileID device management operations​

The paths for the MobileID device management operations have changed. To see what it looks like, use the tabs below:

Get device
GET /devices/{deviceId}
Update device
PUT /devices/{deviceId}
Delete device
DELETE /devices/{deviceId}
Get transactions
GET /devices/{deviceId}/transactions
Get geofencing
GET /devices/{deviceId}/geofencing
Put geofencing
PUT /devices/{deviceId}/geofencing
Delete geofencing
DELETE /devices/{deviceId}/geofencing
Get recovery lock
GET /devices/{deviceId}/recovery-lock
Put recovery lock
PUT /devices/{deviceId}/recovery-lock
Want to learn more?

To learn more, see the Device management resource in our MobileID API reference documentation.

MobileID registration operations​

The paths for the MobileID registration operations have changed. To see what it looks like, use the tabs below:

Start registration
POST /registrations
Get state of ongoing registration
GET /registrations/{transactionId}
Cancel ongoing registration
DELETE /registrations/{transactionId}
Want to learn more?

To learn more, see the Registration resource in our MobileID API reference documentation.

For an overview of the changes to this operation, see the table below:

MobileID authentication operations​

The paths for the MobileID authentication operations have changed. To see what it looks like, use the tabs below:

Start authentication
POST /authentications
Get state of ongoing authentication
GET /authentications/{transactionId}
Cancel ongoing authentication
DELETE /authentications/{transactionId}
Want to learn more?

To learn more, see the Authentication resource in our MobileID API reference documentation.

For an overview of the changes to this operation, see the table below:

Why have response fields been removed?

ReuseID responses simplify the nested device and user objects by removing fields that you can fetch separately when needed.

MobileID signature operations​

The paths for the MobileID signature operations have changed. To see what it looks like, use the tabs below:

Start signing
POST /signatures
Get state of ongoing signing
GET /signatures/{transactionId}
Cancel ongoing signing
DELETE /signatures/{transactionId}
Want to learn more?

To learn more, see the Signature resource in our MobileID API reference documentation.

For an overview of the changes to this operation, see the table below:

Why have response fields been removed?

ReuseID responses simplify the nested device and user objects by removing fields that you can fetch separately when needed.

MobileID account recovery operations​

The path for the MobileID account recovery operation has changed. To see what it looks like, use the tabs below:

Get recovery details
GET /recoveries/{transactionId}
Want to learn more?

To learn more, see the Get details of account recovery endpoint in our MobileID API reference documentation.

For an overview of the changes to this operation, see the table below:

Why have response fields been removed?

ReuseID responses simplify the nested device and user objects by removing fields that you can fetch separately when needed.

Identity verification operations​

The paths for the identity verification operations have changed. To see what it looks like, use the tabs below:

Add identity verification
POST /id-verifications
Get identity verification
GET /id-verifications/{proofingId}
Want to learn more?

To learn more, see the Identity verification resource in our MobileID API reference documentation.

For an overview of the changes to these operations, see the tables below:

Add identity verification​

Changes to the operation for adding an identity verification:

Get identity verification​

Changes to the operation for fetching an identity verification:

On this page