User
The users endpoint allows you to perform a series of actions such as creating, deleting, or updating your users. Each section below describes a different action.
Each call to the API requires an action and a group_id, but often, user calls will include doc and clogin_id.
Name | Type | Required | Description |
action | string | true | This describes what you would like to do with the API. Actions include create, create_child, login, update, add_product, add_email, get_info, set_status. |
group_id | integer | true | This designates which project the change should be applied to. API-id in the header must be part of the organization that owns the group. |
clogin_id | integer | true* | This is a central login ID which identifies a single user between any projects within your organization. |
doc | JSON | false | This is the user data you would like to include in the request, formatted as JSON. |
* This is mandatory on all calls except for create, since a new user will not yet have a clogin_id.
Name | Type | Required | Description |
connected_to | integer | false | This is the clogin_id of a parent and is only relevant in family systems. |
submit_forms | boolean | false | This prevents the user's forms from submitting. This is generally advised if you want to prevent the update from activating triggers which are set in your project. false will prevent the forms from submitting, but true is the default. |
disable_email_sending | boolean | false | This specifically prevents any emails from automatically sending as a result of an API call. true will prevent the emails from sending and false will allow emails to be sent. Although false is the default, it is generally advised that you set this to true if you're not sure of what emails might trigger. |
With every call to the API that involves the users endpoint, the system will return at least two objects by default: meta_info and user_info. meta_info provides a summary snapshot of the user's progress, while user_info is provided as a convenience for user identification,
Examples of each are below:
The key thing to note is that connected_to relates child to parent. For a parent or an individual, connected_to will be identical to their own clogin_id, while for a child connected_to will be clogin_id for their respective parent.
This would be an example cURL which creates a user.
