.system. This user is an all-powerful user with the following (non-overridable) configuration:
.systemcannot send messages to, join, or remove itself from any channel.
.systemcannot login and cannot issue a token for itself.
.anonymous. This user has absolutely no privileges and cannot call any API without it erroring.
screenNamefield is intended to be a visual aid for developmental purposes.
@typementoning the type of locator it encodes (
tele). The structure for an email is:
@type:<serialized-format>. Each locator type defines its own serialized format. For the email locator, it is as is defined in the RFC 822 format and for a phone number it must be in the E164 format. Examples of this would be:
attributesand to each attribute an associated
value. There are no restrictions on the name or type of the attribute, and they can be fixed depending upon the use case of your application. For instance, one would wish to store the 'First Name' and 'Last Name' of a user in their profile, so the two attributes the application could use is
lastName. Once these two attribute defs are created, users can now set their profile data. To set the users first name and the last name:
timeToLiverepresents a static presence. This User's presence will now not be changed unless an explicit API call is made. To get the presence of a user:
expiresToobjects can be chained to any degree. For instance, if you wanted that when a user is inactive for 10 seconds, change the status to 'Away', if for 20, then change it to 'Inactive' and for any time more than 30, set it to 'Offline'
timeToLivefor a presence is the time the presence will stay active from the time it is set. So in the above case, all the nested
expiresTocall have a
timeToLiveof 10 seconds, since the time is counted from the instant they are set as the users active presence.
/v1/users. A user can only be created using an application access key/secret.
userIdis not supplied, one will be generated.
DELETEcall with the user-id in the URI. This API can be called only with a application access key/secret.
GETcall as below:
NOTE All APIs above can also be called by an authenticated user to fetch details for themselves by using
meas the user identifier. These API calls are not allowed for
.systemuser, i.e. using the application access key/secret.
.systemwill have to issue a token. However, a User can extens the
ttlbefore the expiry time.
signedTokenis the token that is to be set as an HTTP header whenever making requests on behalf of this User. The name of the header(s) which can hold this value is provided in the
supportedHeadersfield. In addition to this, a
tokenIdis already returned which can be later used to revoke this user's tokens.
DELETEcall on the
.systemuser, or by any other user for themselves.
GETmethod and not the
DELETEmethod so as to allow this to be a clickable link that can logout users that can be handled by browsers.
signedTokenis not returned again. This is an API purely for reference purposes. The
ttlgives the approximate number of seconds left before this token expires.
.systemuser can fetch tokens for other users. For an authenticated users, they could also: