Notice: Your site will use Java, PHP, or .Net technology? Have a look at our SDK´s in order to have a rich set of fetures for accessing these APIs.  By removing the need to manage access tokens manually, the SDK greatly simplifies the process of authentication and authorizing users and apps for your project.


In order to have access to User API, you must have permits on the following authorization layers:

  • You will have  app credentials (client ID and client secret).  You can create app credentials for your site via DRUID cockpit.
  • The app credentials must be active.
  • The app credentials must be authorized to obtain application tokens via client_credentials mechanism (see permissions tab in apps configuration).
  • The app must be authorized to access User API resource server (see perrmissions tab in apps configuration)


The User API is used so that applications integrated with DRUID can consult the personal data of the users registered in your database. The API posts operations that use the access tokens and client tokens obtained in the OAuth authentication process.

Endpoint URL

POST https://{}/api/user

Request headers


Request parameters

oauth_tokenclient token obtained in the OAuth process. It can also be an access token, in which case the data relating to the user that generated the token will be returned.yesstring
ff: would be the equivalent of “from” in a query. For the time being, it should take the User valuenostring
swould be the equivalent of “select” in a query.
With s=* you’ll get all the user fields.
With s=? where ? is the name of a field (see field names).
You’ll only get that user field and as many field names as you want can be nested by adding more than one s=?.
wThe equivalent of the “where” clause in a query.
With w.?=value where ? is the name of a field (see field names) you’ll only get data of users that meet the condition.
where conditions may be nested in the form w.field1=value1& w.field2=value2&w.field3=value3 …

Response json example

Response parameters

Base fields
UniqueidUnique identifier for the useryesyes
UniqueoidThe unique identifier given the user entity.nono
flagopt-inDetermines whether the user accepts to receive communicationsyesno
enumpropertyThe name of the property associated with the entry point by which the user is registeredyesno
stringentry-pointThe entry-point key by which the user is registeredyesno
stringcountry_iso_codeUsually determines the origin country of the user. Exactly is the country code associated with the entry-point for which the user registered. see
enumtypologiesList of typologies to which the user belongsnono
flagconfirmedIt determines whether the user has confirmed at least one identifier (see identifiers table).nono
enumbrandThe corresponding brand of the registered user. Exactly is the associated brand with the entry-point for which the user registered.nono


Example 1: Select all the fields of a user with a specific id

Requirements:Fields to be returned: all

  • User id: 1
  • Valid client token

The request would be as follows:

Example 2: Select all the fields of a user through their Access Token


  • Fields to be returned: all
  • Access Token: valid and belonging to a user

The request would be as follows:

The response would be the same of the example 1.

Tips and cautions on using user data query

About the parity table

It’s probable that the consumer application of the user API service needs to maintain a parity table between your own application and DRUID users. This table would relate the identifier of the application user with the identifier returned by the DRUID User API.

The consumer application may not even have own users but works directly with DRUID users and it wants to save this user identifier.

For either of the cases, we recommen saving this information (relation if it doesn’t exist or new user if it doesn’t exist) when the user first authenticates and their data subsequently consulted through this API.

About storing user data retrieved from User API

It is not recommended (except in exceptional cases) that the data of a user consulted using the User API, such as name, mail, etc., are stored by the consumer application of the service. This primarily for two reasons:

  • Possible referential integrity errors between the User API data and the application consuming the API. As if the user updates their data, the data will be different between the two systems.
  • Possible legal issues regarding data management. If the consumer application wants to store the data returned by the API, it must undergo the neccesary processes to maintain data confidentiality and legality with your Company.