iDIN offers their own custom UI. This means that when integrating the eID into your service, the end user will be redirected to the eID provider's webpage - hosted on the provider side. The provider's webpage cannot be iframed due to security considerations and is imposed by the providers themselves.

Since the end user will only need to interact with the provider's webpage, we recommend to use an "API-only flow", which means you won't be using Scrive's eID Hub frontend. However, this may depend on if you are also looking to integrate more eIDs who might not offer their own custom UI.

When using the API-only flow, you create and start a transaction from your backend application, then you redirect your end-user to the authUrl or signUrl. After that, the end-user is redirected back to you. You will further need to collect the completion data about the performed transaction. See the diagram to the left.

If you choose to work with the Scrive eID Hub frontend, you can use the same flow as with other providers and use accessUrl returned when creating a new transaction. In this case you do not need to start the transaction, since it is done by the eID Hub frontend.

The iDIN pricing model has two options:

Full identification: the end-user's details are returned (name, date of birth, gender, address, etc.)
Repeated identification: only internal userID is returned

To follow the repeated identification option, one needs to make sure to not request any user data, setting all request* flags to false when creating a new transaction.