User registration (onboarding)

Kate Santo Updated by Kate Santo

When a user downloads and opens an app for the first time, they follow the onboarding journey you'll find documented here.

See for yourself

  • You can download the iOS or Android app on your phone to follow this journey along. And you can also log in or sign up to the web app here
  • You can also follow along by checking out the images or code snippets in this guide
  • And you will find the relevant endpoints linked and explained in this guide, but the full API is documented in Swagger UI

Journey explained

  1. The user opens the app
    1. The user is presented with several onboarding screens the first time they open the app. These screens showcase some app features and are stored within the app bundle
    2. The getClientParameters endpoint is called. The payload contains critical information about the client. Things like T&Cs (see step 2), brand name and sign up restrictions are specified here
    3. The final thing that happens at this point is that the Firebase SDK is launched. It generates a device ID that allows notifications even if the user hasn't signed up yet. This ID is unique to the user's device and is sent to our API when the user signs up successfully. Overall, Firebase does 3 things:
      1. It's an analytics tool
      2. It's a mechanism to deliver push notification to devices
      3. It reports stability issues on the platform
  2. User is then presented with T&Cs
    1. The URIs for T&Cs, Privacy policy and FAQ are in the getClientParameters endpoint. That part of the response looks like this:
    2. {
      "termsAndConditionsUri": "",
      "privacyPolicyUri": "",
      "faqUri": ""
    3. When the user accepts the T&Cs and the Privacy policy, which is necessary to progress in the journey, the termsAccepted property in the user profile gets its value updated to true
  3. The user is asked to enter an email address or phone number to sign up to the app
    1. The button here calls the createChannelIdVerification endpoint, which takes the email address or phone number the user entered and sends an email or sms with a verification code. The verification via sms is handled through a Twilio integration
    2. At this stage, the app is creating a token to verify the user. This token is short lived: expires after 15 minutes
  4. On the verification screen, the user enters the code they received in the previous step
    1. When the use enters the last digit of this code, the grantAccessToken endpoint is called and the user is authorised
    2. If the code is not valid (because the user entered the wrong digits or because it expired), step 3a needs repeating and the user requests a new code using the option on screen
  5. The user creates their profile in the app
    1. The user is asked to take or upload a picture
    2. The user is asked to enter their user name, their password and their date of birth. The user name will be used by default when the user creates a persona to join a padoq, unless the user provides a different persona name [link to user/persona explanatory content if there's some]. The password is validated by the password policy outlined by the app host (our API). And the date of birth is also validated -the user needs to be over 13 years old
    3. When the user taps the 'Continue' button, 4 things happen:
      1. The addUser endpoint is called. This takes two parameters: the verification code from step 4 and the ID of the requesting client. The username, password and date of birth properties get their values from the information the user entered
      2. The provisionAvatar endpoint is called. This gets the location where the image that the user took or uploaded will be stored
      3. The uploadAvatar endpoint is called. This uploads the profile image into the location that was set in the previous endpoint call
      4. At this point, the user is also assigned to a partition. When a new user onboards a Padoq app, the new user credentials are assigned to the partition where that app lives. And we may have more than one app in the same partition. This means that the credentials created in one app will work in any of the apps that share a partition. If the same user then onboards an app that lives in a different partition, they will be creating brand new credentials that will only work in apps within that same partition.
  6. The user is next asked about their location. This information is used to find padoqs that are near the user's location
    1. The location details are taken from the user's device location data or the user can set their location manually. When the location is set, the updateUser endpoint is called and the value of the location property is updated with the new information
    2. The location property is optional in the user model, so the user can skip this step if they wish. There is an option for that at the top of the screen
  7. The user is finally asked to select 3 or more interests. This is used to find padoqs that are relevant to the user
    1. Once the user has selected their interests, the updateUser endpoint is called and the value of the interestGroups property is updated
    2. The interestGroups property is optional in the user model, so the user can skip this step if they wish. There is an option for that at the top of the screen
    3. At the end of the process, a user's profile might look something like this:
    "username": "jsmith",
    "gender": "FEMALE",
    "emailAddress": "",
    "phone": "+15005550006",
    "displayName": "Juliet Smith",
    "givenName": "Juliet",
    "familyName": "Smith",
    "dateOfBirth": "1999-01-01",
    "location": {
    "name": "Europe/Manchester",
    "coordinates": [
    "registrationTimestamp": "2002-08-03T21:42:35Z",
    "termsAccepted": true,
    "interestGroups": [
    "padoqViewOrder": [
    "attributes": {},
    "clientAttributes": {},
    "failedLoginCount": 2,
    "payerId": "string",
    "privileges": "string",
    "avatarUri": ""

How did we do?

The Padoq platform

User profile