URL

POST https://{{client}}.api.451.io/v2/users/export

Headers

• Authentication = Bearer {{api_key}}
• Feature = {{feature}}

Body Schema

In general, there are two ways you can build a schema for exporting data out of Element:

• Pre-defined/Element template

  {
    "item": {
      "template": "",
  			...
      }
  }
  

  • The template can be passed inline in the request body itself as an object/array (what is shown below) or if there's an existing template in the system a guid can be passed as a string (what is shown above). If no template is provided, it defaults to returning only the Element User ID.

• Inline template

  {
    "item": {
  		 "columns": [
  			 {
  				 "field":"",
  				 "mode":"",
  				 "slug":"",
  				 "transformations":[],
  				 "validations":[],
  				 "empty":""
  			 }
  		 ],
  		 ...
      }
  }
  

  • When building an inline template, the properties are as follows:
    • "columns" : [array] - (required) list of object properties to be exported for each row (you could also review How to Reference a Segment below to see how to get this from the UI).
      • "field" : "string" - (required) Friendly name of the field to be exported.
      • "mode" : "string" - (required) Generally should be set to “slug”. Other options include “skip” and “calculated”. For skip, this skips exporting the data for that specific slug. The field name and slug name (can be any text string) still need to be populated in the template. For calculated, the formula value needs to be included in the template.
      • "slug" : "string" - (required) Slug of the referenced Mapping.
      • "transformations" : [array] - (optional) Any transformation to be applied on the value.
      • "validations" : [array] - (optional) Any validation to be applied to the value.
      • "empty" : "mixed" - (optional) Action to do when the value is empty.

The full body scheme (after the template or inline column), can look like this:

{
  "item": {
    ...
 
    "users": [],
    "segment":  "" or [{...},{...}],
		"per_page": #,
    "last_id": "",
    "options": {
      "column_key": ,
      "unwind":
      }
   }
}

• "users": [array] - (Not required if using segment mode below) - List of users to export. Limited to 50 users per request.
• "segment" : "mixed"- (Not required if using user list mode above) The segment can be passed as a raw inline segment in the request body itself or if there's an existing segment on the system a guid can be passed. (see How to Reference a Segment below)
• "per_page": integer - (Optional, default & max:50) How many users information you want to retrieve for a single request. Cannot be more than the default value.
• "last_id" : "string" - (Optional, default:null) Is used to access the next page in the result set. For the first page it must be NULL or not specified. On each response received under “meta.next_last_id” the value you need to specify to pull the next page will be listed. You will find the last page when there are no rows in page content or “meta.next_last_id” value is empty in response.
• “options”: object - (optional) Configurable options for the export task.
  • "column_key" : “string” - (default:field) Generally should be "slug" and it will affect the resulting json object keys for each row. When using "slug" given none slug columns will not have a key.
  • "unwind.root": {object} - Any entity you want to use for unwinding user rows, creating a “row” of data for each item in the object. If you are exporting repeaters using root mappings, don't use this option. (Example - { "root" : "user-applications-root" }). There are some grouping, like conversations, that are not available through root mappings and require the unwind option.

Example 1 - [user list] basic, using slugs as keys

Example 2 - [user list] with unwinding applications

Example 3 - [user list] with root mappings