[[email protected]#][[email protected]$#]*
.system
. This user is an all-powerful user with the following (non-overridable) configuration:.system
cannot send messages to, join, or remove itself from any channel..system
cannot login and cannot issue a token for itself..anonymous
. This user has absolutely no privileges and cannot call any API without it erroring.screenName
field is intended to be a visual aid for developmental purposes.@type
mentoning the type of locator it encodes (email
or 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:email:[email protected]
tele:+911234567780
attributes
and 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 firstName
and lastName
.type
would be firstName
.text/plain
].identity
].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:timeToLive
represents 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:timeToLive
and an expiresToPresence
:expiresTo
objects 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'timeToLive
for a presence is the time the presence will stay active from the time it is set. So in the above case, all the nested expiresTo
call have a timeToLive
of 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.userId
is not supplied, one will be generated.DELETE
call with the user-id in the URI. This API can be called only with a application access key/secret.GET
call as below:NOTE All APIs above can also be called by an authenticated user to fetch details for themselves by usingme
as the user identifier. These API calls are not allowed for.system
and.anonymous
.
locators
:PUT
request:.system
user, i.e. using the application access key/secret..system
will have to issue a token. However, a User can extens the ttl
before the expiry time.signedToken
is 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 supportedHeaders
field. In addition to this, a tokenId
is already returned which can be later used to revoke this user's tokens.DELETE
call on the tokenId
:.system
user, or by any other user for themselves.GET
method and not the DELETE
method so as to allow this to be a clickable link that can logout users that can be handled by browsers.signedToken
is not returned again. This is an API purely for reference purposes. The ttl
gives the approximate number of seconds left before this token expires..system
user can fetch tokens for other users. For an authenticated users, they could also:.system
or .anonymous
.