This allows you to update values on fields on your applicants forms. This is broadly similar to get_info, except that its scope is limited to updating fields and does not include system fields (anything which starts with an underscore, such as _usercart). For adding products see add_product.

Parameters

Example

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" \ 
     -H "Timestamp: 2514736251" \ 
     -d '{
    "action": "update",
    "group_id": 100909072,
    "clogin_id": 102670541,
    "connected_to": 102670540,
    "doc": {
        "your_instrument": "piano",
        "will_you_record_an_album_with_jimi_hendrix": [
            "no"
        ],
        "f_251473_6251473": "a field id looks like f_251473_6251473 by default, and has words like your_instrument only when you map it"
    }
}



Response

{
    "msg": "User updated.",
    "system_action": [
        "user_updated"
    ],
    "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
    }
}

Validation and Troubleshooting

It is important to note that there are a number of behind-the-scenes validation actions that are occurring whenever you attempt to update a user via the API. To get an overview of the basic validation options for each type of field make sure to check out the section on fields.

Situations in which no updates occur

There are three common scenarios in which an update call will be made, but no information will be updated for the user.

• If you attempt to update a user that does not exist in the project, the system will not update any information.  
• If you attempt to update a user that does exist but the answer to the field (such as a multiple-choice answer; see more below) or the field itself does not exist, then the system will not update any information.
• Finally, if you attempt to update a user who does exist but they do not have the form that contains the field you are trying to update, then the system will not update any information.

Additional multi-select validation

As mentioned in the section on fields, multiple-choice fields should be sent in the API as an array of strings where a single answer update is an array of length one. When a string within this array is parsed, we first test whether the string matches any of the existing values within that field. If no match can be found, then the HTML is stripped from the string, and the entire string is converted to lowercase. If after this the string still doesn't match any of the values within your project, then the system would proceed to not update the value. 

The trouble with triggers

If a call is otherwise correct and you set submit_forms to false, then a few specific things happen: The value will save as expected, and the form on which the field exists will not submit for the user. The effect this has in practice is that it prevents subsequent triggers within forms, emails, products, etc. from reacting to the submission of the form. This being said, if there are any fields that are triggered to show within the form itself in response to the value you are updating, then those triggers will still activate. Generally this is not a big deal, and the emails, products, or subsequent forms are the things you're worried about activating.