If you do not already register customers on your side including correct consent handling, you must register users with consent in the Liquid Barcodes system.
The application identifies itself/the user in a two-stage process, which is normally only carried out once. However, the LIQUID services have the ability to force a re-registration either explicitly (hard) or implicitly (silent).
Registration flow
The high-level registration process is described and illustrated below:
- 1. Execute POST /initialize
The application identifies itself with a unique and persistent Device ID. As a response, a temporary UserId is given from the system.
Besides, an array of consents is given. The API supports two types of consents: Master consents and Non-master consents. Master consent is identified through the consent situation model parameter
Name= ‘Master’. The user should accept Master consent on registration. As a minimum, the user should be presented with the consent model title and link to the Privacy policy text. Both texts are provided and can be provided as HTML converted from markdown.For future updates of consents, see the Consent Update section below.
- 2. Execute POST /pin
In this request, the application sends a phone number together with the temporary UserID. The user is then sent a PIN on SMS on the indicated number.
- 3. Execute POST /user
This request should be executed with the unique temporary UserID, the received PIN code, and consent acceptance (and Date Of Birth if consent requires a minimum age). In addition, other information about the user may be added. Upon verification from the system that the UserID and PIN match, the application gets a final UserID. The final UserID is either the same as the temporary UserID (user has never registered before) or a new UserID (in the case where the user has previously registered). The function returns the processed user model.
Note: store the UserID locally, not in clear text.
- 4. If still missing user information or any edition is wanted to be done, execute PUT /user call.
Granular consents
Non-master consents provide options for granular consents that can be handled after the main registration process or on the User's profile page. We advise presenting users with all granular consents on one page. Present consent model title and link to consent model description.
It is important to note that several application instances can share the same UserID if a particular user installs and register the application on several phones (as long as he has access to the phone that gets the PIN).
Consent Update
The API supports breaking and non-breaking changes. If a breaking change to either the Master consent or the Granular consents is introduced, users should accept the new consent texts.
The API may provide a change description for each consent update back to the previously accepted consent version. Note that there may be several new versions and corresponding change log texts for one user.
Master consent
Breaking changes on Master consent will block the app from getting content until new consent has been accepted. Prompt user with updated consent version to restore app functionality. The app should check for, at regular intervals eg. daily, and warn the user about non-breaking changes to Master consent. In case of non-breaking changes, the state in the Consent situation model will be set to 'ConsentRenewalRequired' for the Master consent. Use GET /user to retrieve updated consent texts.
Granular consents
User can continue to use the app even if there is a breaking change to one or multiple granular consents. The app should check for, at regular intervals eg. daily, and warn the user about any changes to Non-master consents. If change is identified, give the user the option to renew consent. In case of changes to the granular consents, the state in the Consent situation model will be set to 'ConsentRenewalRequired' for the applicable consent(s). Use GET /user to retrieve updated consent texts.
