| Expand | ||
|---|---|---|
| ||
|
...
| Info |
|---|
You need to provide your integration API key for authentication in application calls towards the platform. Note the error messages that may be related to this. |
| Info |
|---|
Refer to CDIServer API for the base path required in all calls to the API endpoints. |
...
Checks on sign-in
There are a number of checks that your application should perform when users are signing in to your application or before they access a certain section of your application. If you allow them to sign in without these checks being performed, they will still not be able to utilise platform functionality, like creating transactions, once the platform performs these checks.
Which sign-in checks you need to perform depend on the user representation types you are utilising in your application. Verify that the user accounts and accesses utilised in your application are active. Read more about user accounts in Concepts and, if available, your case-specific Lequinox compliance study.
Roles – focus on external user accounts
Always use external roles to invite users to your Lequinox enabled application. To invite users, you first need to create a role that you can assign them to.
...
Follow the instructions to Create an external role.
Create external role accounts – assign a created role
In the Lequinox platform, organisation/corporate users are represented by their role account. Via this role account, they are assigned to a role.
...
On the same page, you will also find information on how to update an external role account and what happens when you update an external role account.
Create access for platform-managed external role accounts
The access represents a relation between an application and a certain user account in the form of an identity with separate keys which can sign transactions individually in order to create traceability for the application when a user acts in a role account or personal account. If your organisation wants to interact with a user in another organisation, create an external role account and an application access for them. If they want to interact with an individual outside their own organisation, that is, as a natural person, create an external personal account (in the REST API referred to as an ‘external personal identity’) for them, and then provide this with an access. With the access, the user can work with transactions within the application. There are two types of accesses – organisational (in the REST API referred to as ‘corporate’) and private. Organisational accesses are intended for business-to-business relations, whereas private accesses are intended for business-to-consumer or consumer-to-consumer relations.
...
| Info |
|---|
Only create accesses for platform-managed role accounts. |
Activate a platform-managed access
After a platform-managed access has been created, it must also be activated before it can be utilised. Either the platform can activate the access when it is created, or it can be left to the user to activate it, depending on application owner preference. Although not required, you can let your application present the user with an end user agreement that they need to accept before their access is activated (step 1 below).
...
On the same page, you will find information on how to update an access, if needed.
Managing transactions via the application server account
To create transactions with the server account as the creator, the platform can create the transaction for the application.
Here, the application must also have functions for opening and signing these transactions via the application server account.
Managing transactions for platform-managed accounts
Using platform-managed user accounts (internal role accounts, external role accounts and external personal identities), the platform can create transactions as platform-managed users.
...