User Information

Returns information about a user of the account.

When no other user is specified, it returns information about the user_id used to make the API calls. Mostly used for continuous validation of a user past the login screen on front-end store applications, since incorrect credentials will return an error message, and correct ones will return information about the user including their permissions level which could be tainted if stored in a cookie or as hidden form data.

Headers

The data to be submitted to the API is composed of the following fields:

Notes:

• Headers: the user_api_key value can be included in either the header section or the body of the request. If the key is provided in both locations, the API will process and validate only the value provided in the headers.

• The user_password to be provided is the API key, not the actual typed-in pasword on a form field. To login a user with a typed-in password, please contact us for acess to the Enterprise Level API.
• The parameter user_name is optional: It refers to the user_id of another user about whom information is requested. If it is given, then information about that user will be returned. If it is ommited, then info about the user making the call (user_id) will be returned.
  • If this seems contradictory or complicated, look at it from this scenario: To continually validate a user with the password they typed in, this password would have to be stored locally and passed back to the API with each screen or API call. This could be a security issue as the password could be gleaned from the local storage, hidden form data, or cookie. If you were to also store the permission level, a person with a low permission level could edit the stored data to give themselves a higher permission and access capabilites on your app that they shouldn't have access to. Hence this call without passing a separate user_name allows for verifying this data at any point.
• If suppress_permissions or terminal is passed with a Yes value, the list of permissions is not returned. If you ommit this parameter, the permissions list is returned by default. terminal is an alias of suppress_permissions.

Example PHP Request:

If you are using PHP, the $data array would look like this:

1. $data['user_id'] = 'john1970';
2. $data['user_password'] = '1959caadac9b13dcb3';
3. $data['type'] = 'user_info';
4. $data['account_id'] = 'greatwidgets';

Success XML Response -- Account Owner credentials only:

1. <response status="success">
2. <user>
3. <user_id>johnnyclerk</user_id>
4. <user_is_owner>true</user_is_owner>
5. <user_biz_name>Demo Co.</user_biz_name>
6. <user_language>EN</user_language>
7. <user_timzone>14</user_timezone>
8. <user_level>A</user_level>
9. </user>
10. </response>

NOTES:

• Account Owner user accounts do not have first_name, last_name, or addtl_info fields
• Account Owners are always level "A". This is included even if not needed to simplify permission checks at the application / integration level.
• Timezone and language code tables are available on the menu on the left.

Success XML Response -- Account Users credentials:

1. <response status="success">
2. <user>
3. <user_id>johnnyclerk</user_id>
4. <user_is_owner>false</user_is_owner>
5. <user_first_name>John</user_first_name>
6. <user_last_name>Smith</user_last_name>
7. <user_addtl_info>store 35</user_addtl_info>
8. <user_language>EN</user_language>
9. <user_timzone>14</user_timezone>
10. <user_level>K</user_level>
11. </user>
12. </response>

NOTES:

• Account Users do not have a biz_name field.
• timezone , language, and user_level code tables are available on the menu on the left.

Error XML Response:

1. <response status="error">
2. <error>Error message</error>
3. </response>