Stability: 3 - Stable


Storing user specific data on Hydra is built around the Account. The account can hold any user data that you would want to use across more than one game. For storing player stats specific to your game, you should use the profile. We will eventually launch a feature that allows a single developer or publisher to launch multiple games with shared accounts. Think of it as your own single sign-in.

Accounts are automatically created when the requested authentication credentials have no associated account. When an authentication token is generated, a profile will be initialized for the game linked to the Account.

In an account, you should expect to see the following information:

   "created_at":"2012-11-08 16:41:46",
   "updated_at":"2013-02-06 22:03:57",

Data can be retrieved in raw JSON format for you to parse on your own. Additionally, each of our SDKs provide methods for retrieving specific stats and data from a user’s account.


Each account has unique information for its user, stored in the Identity object.

Username : string
A unique value that should act as the user’s primary identifier. You can update stats and award achievements all based on the username.
Avatar : string
A URL pointing to the location of the user’s avatar image. (Avatar can be a maximum of 100 KB.)
Email : string
A unique email associated with your user’s account. Useful for account recovery.
Default Username : boolean
True if the username is the generated one from account creation.

You can get the user’s identity data.

  • [client.myAccount getIdentity];
  • client.MyAccount.Identity;
  • client.getMyAccount().getIdentity();
  • client->getMyAccount()->getIdentity();
  • Documentation coming soon.

You can also update it with a new identity object.

  • http
  • AGPromise *p = [client.myAccount updateIdentity:identity];
    [p when:^(NSDictionary *response) {
        // ...
  • client.MyAccount.UpdateIdentity(identity, delegate(Request request)
        // ...
  • client.getMyAccount().updateIdentity(identity, new ObjectListener<Account>() {
        public void objectReceived(Account account, Response response) {
            // ...
  • client->getMyAccount()->updateIdentity(identity, [] (std::shared_ptr<Account> account, Request *request) {
        // ...

Alternate Identity

When using multiple authentication schemes (steam, custom, etc) sometimes you wish to show the identity of that scheme not the native identity that Hydra Studio offers. We will track the identity for each of the schemes that the user has linked to their account and refresh it each time they login. We support the same fields that we do for our main identity and will populate them if the backend supports them.

  • Username
  • Avatar
  • Email
  "username": "wild-small-cherry-sound-e3df4",
  "alternate": {
    "custom": [
        "username": "jondoe",
        "avatar": null,
        "email": ""
  "avatar": "",
  "default_username": true

Reference: C++ - getAlternates , getPlatformIdentity


Each account has a list of its currently active Sessions (REST and Realtime). Each Session object contains the following:

ID : String
The Session ID.
Start Time : Date
The time this session was started.
Last Used : Date
The last time this session was used.
Realtime Connection ID : String
The Realtime connection ID (if this Session has a Realtime connection associated with it).
Realtime Start Time : Date
The time the Realtime connection was started.
Status : Object
The status associated with this session

Reference: Unity | Android | C++ | REST

Session Status

The session status is a place to put information about a user’s current session. This information can then be retrieved by mutual followers. There is no required format for this data, developers can update it with whatever they like.

Each Status object contains the following:

data :
The data set by the user when updating their status
Environment ID: String
The ID of the environment where this session was created
Current Environment: Boolean
True if this session was created in the same environment that the client is connected to


You can update the current session for the logged in user. You can optionally tell Hydra Studio to send a notification (Realtime only) to mutual followers about the status update. See our reference docs for more details:

Reference: C++ | REST


If you are loading an account, you must can request status information via the fields argument (connections.status). They are only accessible by mutual followers.


Account security follows the standard security model.

Banning and Kicking

As a developer you have the ability to ban or kick any user via the dashboard. You can also do so via the following endpoints:


The following applies to a banned account:

  • All login attempts will result in a 403 Forbidden response
  • A Banned notification will be sent over Realtime to the account
  • It will be kicked offline - see below

An account ban may be either permanent or timed. For timed bans, an account may log in after the ban expiration date, which will reset the account’s status back to normal.

For timed bans, duration may be set using the optional duration parameter on the ban endpoint. To ban on the order of hours or minutes, an additional units parameter is available, which can be set to ‘weeks’, ‘days’, ‘hours’ or ‘minutes’. When banning, if units is provided, duration must also be provided.


Kicking an account offline results in all its logged-in sessions being disconnected, including Realtime connections which will be dropped by the server immediately.

External Account Linking

Account Linking allows you to associate accounts in external systems (such as Google, Facebook, or even other Hydra environments) with an account in your own environment. This is different than Authentication Linking as Account Linking does not grant any login access with those external systems, nor does it limit the number of accounts that can be linked to the same account on the external system.


Table Of Contents

Previous topic


Next topic

Account Chat