LiveLike

The LiveLike Developer Hub

Welcome to the LiveLike developer hub. You'll find comprehensive guides and documentation to help you start working with LiveLike as quickly as possible, as well as support if you get stuck. Let's jump right in!

Get Started    

Profiles

Extending your user data with LiveLike profiles

Profiles are used to collect activity in chat, widgets, and other features inside a single identity. Profiles can be provisioned arbitrarily and can be used to extend your existing user account records. These profiles can either be local, allowing you to create anonymous experiences, or persisted in your user databases, allowing you to create profiles that persist across a user's devices.

When a profile is first created it is given a unique ID and a credential called an Access TokenAccess Token - Token that grants access to the LiveLike REST API. Access tokens can have two levels: Profile and Admin. Profile access tokens (obtained via the SDK/APIs) allow you to store and access data for specific users, but have restricted functionality. Admin access tokens (obtained via the Producer Site) have no restrictions and allow you full access to the LiveLike REST APIs.. It is also automatically given a nickname if one is not provided. Profiles will persist for as long as its credentials are stored and passed back to the SDKs & APIs. Nicknames are used for personalization, and show up next to chat messages and in leaderboards.

🚧

Nicknames are not unique!

The profile ID and access token are the identifying fields of a profile. Nicknames are not guaranteed to be unique and can often be freely updated by users.

Updating a Profile

const updatedProfile = await LiveLike.updateUserProfile({
  accessToken,
  options: {
    nickname: 'New Nickname'
  }
})
sdk.updateChatNickname(nickname)
sdk.setUserDisplayName("<new display name>") { [weak self] result in
      guard let self = self else { return }
      switch result {
      case .success:
          print("Successfuly changed user display name")
      case let .failure(error):
          print("Error \(error.localizedDescription)")
      }
   }
 }

📘

Looking for chat avatar images?

Avatars are handled as part of the chat system. Read more in the Chat Avatars section.

Local Profiles

Anonymous experiences can be created by persisting credentials in volatile storage, like a session store. These profiles will persist for the lifetime of the store. For example on mobile devices, you can store the profile in local storage. The profile can be reused, as long as the user doesn't clear local storage or reinstall the application.

Workflow for storing profile access tokens locallyWorkflow for storing profile access tokens locally

Workflow for storing profile access tokens locally

Persistent Profiles

Profiles can also be tied to your own user accounts. The user Access TokenAccess Token - Token that grants access to the LiveLike REST API. Access tokens can have two levels: Profile and Admin. Profile access tokens (obtained via the SDK/APIs) allow you to store and access data for specific users, but have restricted functionality. Admin access tokens (obtained via the Producer Site) have no restrictions and allow you full access to the LiveLike REST APIs. can be stored as a field in your user database. That allows you to re-use the same access token when a user reinstalls an app or signs in on another device. To understand how to tie profiles to your user accounts, see Integrating with Logins.

❗️

Track your profiles!

While you can initialize the SDKs and create profiles arbitrarily, each new profile counts as a LiveLike user. If you are using metered MAU billing, it is important that your integration does not generate more profiles than it needs. If you want to keep your profile count in line with your own user count, ensure that each user in your system has only one LiveLike profile associated with them, and that they use the same profile each time they use your app.

Updated 11 days ago


Profiles


Extending your user data with LiveLike profiles

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.