Skip to content

User management

Following are the common use cases for user management. For more details refer to our swagger documentation.

Create user

To create a user, you need to call POST account/v1/user with the user's data. Once created, the user will receive a verification link in the mail. Verifying the email is required for some functionalities, if for instance the user will have their own organizer. Minimal examples follow.

curl -X POST
    --header 'Content-Type: application/json'
    -d '{ "username": "johndoe", "password": "SuperSecret123@","email":"[email protected]"}'
    'https://api.bam.fan/account/v1/user'

 import { BAM, BaseUrl } from 'bam-ticketing-sdk'

 const bam = await BAM.build({ baseUrl: BaseUrl.Prod })

 const newUser = await bam.account.createUser({
      username: "johndoe",
      password: "SuperSecret123@",
      email:"[email protected]"
   })

Invite user

To create a user which automatically belongs to an organizer, you need to POST account/v1/user/invite with:

  • regular user registration fields
  • organization_name set as the organizer to which the user is invited
  • role which the user will have (0-5)
  • if role is 5 (Custom) you need to specify the exact permissions which the user will get in the field granted_permissions To see more about that, go here

Once the user is created and the appropriate permissions granted, you need to create a wallet to be able to interact with the blockchain (ie. buy secure tickets, host events).

Fetch user

By ID

You need to call GET account/v1/user/:id and provide the appropriate authorization to access any user's data. Every user can access their own data by default.

By enrollment ID (wallet ID)

You need to call GET account/v1/user/enrollment/:enrollment-id and provide the appropriate authorization, but no permissions are required. This way you can get their username, id and picture, if they set one. Mostly useful for checking that a user exists.

Change user's permissions

Granting or revoking user's permissions can be done via PATCH account/v1/user/:id/permission. To grant permissions the user calling the endpoint has to have appropriate ones, which are in the format system.change_permissions or system.resource.change_permissions where system and resource are those which are granted. For example, to grant account.user.view the calling user needs to have account.change_permissions or account.user.change_permissions. Fields in the request work the same way as in the invite request. The user needs to log in again to obtain the JWT with the updated permissions.

Change user's info

Changing a user's info can be done via PATCH account/v1/user/:id, authorization is needed. Changing a user's email will require re-verification.

Creating a wallet

To create a wallet you need to POST account/v1/certificate/enroll with the JWT you obtained by logging in, specified in the Bearer header. SAVE the private key which you receive as we do not keep it and we cannot help you recover it. To this identity, all tickets, events and similar will be associated. It is also possible to call the endpoint without authorization, in which case a new user will be created and a wallet created.

Login

Accessing most endpoints requires authorization with the appropriate permissions. Authorization is done via the Bearer header in which the JWT is sent. JWT can be obtained in 3 ways. Optionally if the x-device-id header is specified while logging in it also needs to be sent with all further requests.

Username and password

You need to call POST account/v1/auth/login with:

  • password you specified on account creation
  • username which can be either the username or the account email

The response will contain the JWT.

Wallet challenge

If your user has a wallet created, it is possible to obtain a JWT by signing a challenge payload with the wallet's private key. This is a good way not to bother the user with typing in their login details. It's a two-step process:

  1. POST account/v1/auth/challenge with a randomly generated client_nonce and your enrollment_id, obtaining a nonce which you need to encrypt with your private key.
  2. POST account/v1/auth/wallet with the client_nonce, nonce and signed_nonce fields. If the signed_nonce is properly encrypted, the response will contain the JWT.

Guest

For instances where the user is ethereal(no account on the platform) the POST account/v1/guest/login endpoint will return a JWT with a random enrollment ID which can be used to complete a ticket purchase, for example.

Back to top