--- title: create slug: docs/create docTags: createdAt: 2021-08-04T18:23:39.000Z --- This call creates a user, which is equivalent to a user registering in your project. This call would apply to creating a parent or an individual; you would use `create_child` to create a child in a family system. The arguments that would be included in the doc are described below: # Basic parameters | Name | Type | Required | Description | | ----------------------- | ------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `action` | string | true | `create` | | `clogin_id` | integer | false | This is a central login ID that identifies a user within your organization.

Organizations can have multiple projects that the same user can register in. If you know the `clogin_id` from a separate project, you can use it to connect the accounts.

`clogin_id` should be `false` for a user who is being created for the first time within your organization. | | `group_id` | integer | true | This designates which project the action should be applied towards. | | `doc` | array | false | See doc parameters below. | | `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 that are set in your project. `false` will prevent the forms from submitting, but `true` is the default. | | `disable_email_sending` | logical | 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 which emails might trigger. | Doc Parameters | Name | Type | Required | Description | | ------------------- | ------ | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `username` | string | false | This is the user name that users will log in to the project with. The project will default to requiring an email format.
If you would like to turn the email requirement off, you can do that by editing the login widget within your project.

If left blank, the system will...

1) Confirm `main_email` isn't taken and use it.
2) Check for any existing email (and confirm this email has not already been taken)
3) If there is no email available, the system will generate a value of the form `{uuid}{groupid}@regpacks.com`. If desired, `username` can be something other than `main_email`.

It is not recommended to deviate from an email as the username as a system-generated email will prevent users from receiving important communications such as *forgot password*. | | `password` | string | false | Passwords can be alphanumeric or special characters with a minimum length of 6. If not provided, the system will autogenerate a password that you can access by running a report in your project. | | `first_name` | string | false | This is an important field that is responsible for the presentation of the first name on the user management page. It is strongly advised to include this. | | `last_name` | string | false | This functions like `first_name` | | `org_name` | string | false | Similar to `first_name` but allows an organization name to display on the user management page. Note that in a family project, it is still advised to include `first_name` and `last_name` in addition to `org_name`. | | `main_email` | string | false | This is similar to `first_name` and often serves as `username` as well. Note that email addresses are both validated and checked against a DNS database, however the DNS check can be disabled in the Project Settings if desired. \*\*\*article on project settings | | `_application_date` | string | false | This will default to the creation date if not supplied. This is included in case you want to back-date an applicant's creation date.
Should be formatted in MySQL date format ("YYYY-MM-DD" or "YYYY-MM-DD hh\:mm\:ss"). | | *fields* | string | false | These are the fields in your project, such as multiple choice fields, short answer fields, etc. See "Referencing fields in API calls" for more information on how to supply fields in the API. | # Examples ## Create a new user This is an example which would create a new user in your organization. The key things to note are that `username`, `password`, `main_email`, `org_name`, `first_name`, ​and `last_name` are all supplied while `clogin_id` is `false`. Altogether, this is the equivalent of an end user registering and answering the yes/no question. ### Call :::CodeblockTabs ```curl curl -X POST "https://www.regpack.com/reg/api2/users/" \ -H "Content-Type: application/json" \ -H "Accept: application/json" \ -H "Api-Id: 15263" \ -H "Api-user: api_admin@regpacks.com" \ -H "Api-Token: cd2e514f-7gab-3cde-62fg-51abcd4e7362" \ -d '{ "action": "create", "group_id": 100909072, "clogin_id": false, "doc": { "username": "jim_hall@regpacks.com", "password": "dont_just_play_something_sit_there!", "org_name": "Jim Hall Trio", "main_email": "jim_hall@regpacks.com", "first_name": "Jim", "last_name": "Hall" } } ``` ```python import requests import json users_endpoint = https://www.regpack.com/reg/api2/users/ current_time = str(round(time.time())) headers = { "Content-Type": "application/json", "Accept": "application/json", "Api-Id": "15263", "Api-user": "api_admin@regpacks.com", "Api-Token": "cd2e514f-7gab-3cde-62fg-51abcd4e7362", } payload = { "action": "create", "group_id": 100909072, "clogin_id": false, "doc": { "username": "jim_hall@regpacks.com", "password": "don't_just_play_something_sit_there!", "org_name": "Jim Hall Trio", "main_email": "jim_hall@regpacks.com", "first_name": "Jim", "last_name": "Hall" } } create_new_user_json = json.dumps(payload) create_new_user_response = requests.post(url=users_endpoint, data=create_new_user_json, headers=headers, timeout=10) ``` ::: ### Response ```json { "msg": "User registered.", "system_action": [ "user_registered" ], "success": true, "user_info": { "clogin_id": "102715741", "group_id": "100909072", "connected_to": "102715741" }, "meta_info": { "u_name": "Jim Hall", "total_forms": "2", "completed_forms": "0", "total_user_forms": "2", "total_completed_user_forms": "0", "total_user_mandatory_forms": "2", "total_completed_user_mandatory_forms": "0", "total_order": "0.00", "total_paid": "0.00", "total_balance": "0.00", "status_id": "0", "status_name": null, "status_color": null, "application_date": "Dec 8th 2021 17:20", "application_date_raw": "2021-12-08 17:20:08", "u_comments": "0", "group_id": "100909072", "uid": "4085257", "clogin_id": "102715741", "excluded": "0", "connected_to": "102715741", "total_user_tags": "0", "user_tag_ids": null, "total_non_excluded_children": "0", "star": "0", "admin_initials": null, "admin_color": null, "assigned_admin_id": null } } ``` ## Add an Existing User to a Project This is an example of creating a user who exists in a previous project. Because `clogin_id` is present, the system will pull `username`, `password`, `main_email`, `org_name`, `first_name`, and `last_name` whether they are provided or not (if the fields exist). What this means is that any values you provide will overwrite the previous values. If `clogin_id` cannot be found within your organization, the system will create a new user and return a new `clogin_id`. The system will disregard `username` and `password` if clogin\_id is provided and will not overwrite them with the values you provide in the `doc`. Note that in a family system, only an existing parent can be created, and all child users will be assigned a new `clogin_id`. ### Call :::CodeblockTabs ```curl curl -X POST "https://www.regpack.com/reg/api2/users/" \ -H "Content-Type: application/json" \ -H "Accept: application/json" \ -H "Api-Id: 15263" \ -H "Api-user: api_admin@regpacks.com" \ -H "Api-Token: cd2e514f-7gab-3cde-62fg-51abcd4e7362" \ -d '{ "action": "create", "group_id": 100909072, "clogin_id": 102670540, "doc": { "username": "miles_davis_quintet@regpacks.com", "password": "stop_playing_the_butter_notes!", "org_name": "Miles Davis Quintet", "main_email": "miles_davis@regpacks.com", "first_name": "Miles", "last_name": "Davis", "your_instrument": "trumpet" } } ``` ```python import requests import json users_endpoint = https://www.regpack.com/reg/api2/users/ headers = { "Content-Type": "application/json", "Accept": "application/json", "Api-Id": "15263", "Api-user": "api_admin@regpacks.com", "Api-Token": "cd2e514f-7gab-3cde-62fg-51abcd4e7362", } payload = { "action": "create", "group_id": 100909072, "clogin_id": 102670540, "doc": { "username": "miles_davis_quintet@regpacks.com", "password": "stop_playing_the_butter_notes!", "org_name": "Miles Davis Quintet", "main_email": "miles_davis@regpacks.com", "first_name": "Miles", "last_name": "Davis", "your_instrument": "trumpet" } } create_existing_user_json = json.dumps(payload) create_existing_user_response = requests.post(url=users_endpoint, data=create_existing_user_json, headers=headers, timeout=10) ``` ::: ### Response ```json { "msg": "User registered.", "system_action": [ "user_registered" ], "success": true, "user_info": { "clogin_id": "102670540", "group_id": "100909072", "connected_to": "102670540" }, "meta_info": { "u_name": "Miles Davis", "total_forms": "2", "completed_forms": "0", "total_user_forms": "2", "total_completed_user_forms": "0", "total_user_mandatory_forms": "2", "total_completed_user_mandatory_forms": "0", "total_order": "0.00", "total_paid": "0.00", "total_balance": "0.00", "status_id": "0", "status_name": null, "status_color": null, "application_date": "Dec 8th 2021 17:20", "application_date_raw": "2021-12-08 17:20:08", "u_comments": "0", "group_id": "100909072", "uid": "4085258", "clogin_id": "102670540", "excluded": "0", "connected_to": "102670540", "total_user_tags": "0", "user_tag_ids": null, "total_non_excluded_children": "0", "star": "0", "admin_initials": null, "admin_color": null, "assigned_admin_id": null } } ``` # Triggers When you create a user, the "User Account Created" trigger will fire. This trigger is the essential mechanism that causes the user to have their forms added to their profile. That said, it is possible that other actions in the system are triggered, and these can potentially have unanticipated consequences. If you would like to limit these second-order effects, it is advised that you include the following parameters: ```json /* this disables emails from sending as a result of triggers */ disable_email_sending:true /* while this prevents all forms from submitting, which often triggers actions to occur */ submit_forms:false ``` ## User Account Porting It is important to note that, if you are creating a user in a project that was copied from a previous project *and that user is also both present and not archived in that previous project*, then it will port over all of the user's data. Any fields you provide answers for in the docs will then overwrite that data. As an example, if Roger registers in "Color-con V", picks "blue" as his favorite color, and then you create him in "Color-con VI" with `{"favorite_color":"green"}`, then it will overwrite his answer in the new "Color-con VI" project; otherwise, his favorite color will show as blue. Data cannot be overwritten with empty strings, so the correct way to prevent data from porting would be to archive the user in the original project (from which the new project was copied). This will prevent any fields from porting over *except for* the special user fields (such as `first_name`, `last_name`, etc.).