JSON

‍

Setting up from the customer record 

Setup fields 

destination endpoint - use this text box to control the 

destination url the customer data should be sent to 

this value will be used for an axios.post request with the full 

request model (more info below) as the payload 

api key - use this field to pass an api key if one is needed for 

the destination endpoint 

under only supports api keys passed via headers at this time 

api key header - use this field to set the attribute name that the 

api key should be passed with in the request headers 

The UI to the right will only exist during our development and 

testing phase. Once we have determined the pattern works the 

under team will move this configuration to the company settings 

page and users will only have to press the brackets icon to transmit 

data to the saved endpoint details.

Request model to destination endpoint 

customerInfo - this attribute will contain all customer info and all values currently saved on the customer applicationId? - the under id assigned to the application that the customer was boarded under (can be used for grouping customers by application) 

additional application info can be found on the applicationInfo attribute below 

templateId? - this will be used in place of application id once our new templates flow is released (can be used for grouping customers by template) 

customerId - the under id assigned to the customer that data is being exported from 

ucId - the under id assigned to the user within your company that boarded this customer (can be used for grouping customers by user) 

additional user info can be found on the ucInfo attribute below 

createdAt - the date the customer was created 

customerData (type = {[key: string]: value: any} ) → more details below 

customerIntegrations - this attribute will contain a list of all integration responses that are currently saved on the customer integrationId - an under assigned id for the integration that was run (can be used to group results by integration) integrationLabel - a string with the name of the integration that the response is for 

run - boolean for whether or not this integration was run for the customer 

If a customer has not run any integration the customer integrations array will be empty - otherwise this attribute can be used to skip empty results 

response - the json response our system has saved for this integration if it was run 

errors[] - an array of integration errors if any occurred 

errorLabel - a string describing the error type 

errorMessage - the stored error message 

alloyType - if the integration response was from alloy this will return either KYC (Individual) || KYB (Business) documentPresignedGetUrls - this attribute will be an array of url strings that can be used for subsequent calls to download all documents currently saved to the customer 

each array item is a url that includes pre authorized signatures to download a document from S3 (urls expire after 1 hour) urls can be used with a get method using https 

see more details about what documents can exist in the Supported Under Document Types section below applicationInfo - this attribute will include identifying information about the application the customer was created on (if the application has not been deleted) 

applicationName - a string with the application or template name that the customer was filled out under creatorName - the name of the user who originally created the application or template 

createdAt - the date the application or template the customer was run on was created 

lastModifiedAt - the date the application or template the customer was run on was last changed 

ucInfo - this attribute will include identifying information about the user within under that the customer was boarded under email - a string with the contact email for the user who the customer was boarded under 

userName - a string with the full name of the user who the customer was boarded under 

phoneNumber - a string with the contact phone number for the user who the customer was boarded under 

Customer Data Model 

The customer data attribute on the under request is an object with key value pairs that are currently saved to the customer. Below we will cover how under keys work and the different data types you can expect from under. 

Under data types and corresponding values

Data Type 

Notes 

Example Key 

Example Flat Value(s) 

Example Special 

Value?

Text Field 

Value saved to field key as it was entered

C#ExampleTextField 

"C#ExampleTextField" : "Text Field Value"

N/A

‍

Number Field 

value saved to field key with optional formatting setup in the app editor 

*example has no mask selected

C#ExampleNumberField 

"C#ExampleNumberFiel d": "100"

N/A

Dropdown field 

selected value is saved to field key as a string 

*options are set up in the app editor, first input is the option label and second input is the option value

C#ExampleDropdownFi eld

"C#ExampleDropdownFi eld": "dropone"

N/A

Radio Field 

selected value is saved to field key as a string 

*options are set up in the app editor, first input is the option label and second input is the option value

C#ExampleRadioField 

"C#ExampleRadioField ": "radtwo"

Checkbox Field 

selected value is saved to field key as a boolean

C#ExampleCheckboxFie ld

"C#ExampleCheckboxFi eld": true

Switch Field 

value saved to field key as a boolean

C#ExampleSwitchField 

"C#ExampleSwitchFiel d": true

Phone Field 

value saved to field key with 11111111111 

format 

*country code + 

number w/ no 

formatting

C#ExamplePhoneField 

"C#ExamplePhoneField ": "13177120510"

Date Field 

value saved to field key in ISO String Format

C#ExampleDateField 

"C#ExampleDateField" : "2024-01- 

04T06:00:00.000Z"

‍

Checkbox List Field value saved in two different formats (both 

will be present in the 

customer data) 

Flat Values - each 

selected value is saved 

individually to 

fieldKey.optionValue 

as a boolean 

Special Value - values 

C#ExampleCheckboxLis tField 

"C#ExampleCheckboxLi stField.checkone": true 

"C#ExampleCheckboxLi stField.checktwo": true 

1 2 3 4 

"C#ExampleCheckb "checkone", 

"checktwo" 

]

are also saved to the 

field key as an array of 

optionValue: boolean 

*options are set up in 

the app editor, first 

input is the option 

label and second input 

is the option value 

Must Be Equal To X Field

values saved in two different formats (both will be present in the customer data) 

Flat Values - each value is saved individually to fieldKey.keyMadeFrom Label (see below about how keys are made fromlabels) 

Special Value - values are also saved to field the field key as an object of 

1 

fieldKey: { 

2 

keyMadeFromLabe 

3 

keyMadeFromLabe 

4 

}

*sub fields are setup in the app editor, label is entered and key is automatically created by removing label 

spaces and casing 

C#ExampleMustEqualX Field

"C#ExampleMustEqualX Field.xvalueone": "50" 

"C#ExampleMustEqualX Field.xvaluetwo": "50"

1 

"C#ExampleMustEq

2 

"xvalueone": "5

3 

"xvaluetwo": "5

4 

}

Click to Agree Field 

value saved to field key as boolean

C#ExampleClicktoAgree Field

"C#ExampleClicktoAgr eeField": true

‍

Auto Complete Address 

Field 

address line 1 value is saved to field key as a string. All sub fields (line 2, city, state, zip) are also saved to their 

respective field keys 

*auto complete 

address is setup in the app editor and the sub fields are all treated 

C#BusinessAddressAuto Complete 

"C#BusinessAddressAu toComplete": "123 test address" 

…remaining fields follow above rules for their respective data types 

normally for their 

respective data types

Same As Field 

same as field value is saved to the field key as a boolean. When this boolean is true all values in the component are copied according to how it was setup in the app editor. If the boolean is false than the customer filled these values out themselves. 

*same as fields are setup in the app editor and values are handledand saved following normal rules for their respective data types

C#SimilarBusinessAddre sses 

most common use case for this is same as address fields or same as bank fields 

example: 

field label → Check box if legal address is the same as business address

copied fields follow 

above rules for their 

respective data types

‍

PDF Default Field Names Disclaimer 

Our pdf mapping product differentiates from pdf only fields using prefixes within their field ids. These field ids are auto generated whenever a field is dragged from the custom field generators section onto the pdf (image shown below on the left). If the keys are changed to a custom key of your choosing the data will save correctly. You can edit and confirm these fields by clicking the appropriate box and updating the form field name attribute (image shown below on the right) 

PDF data types, corresponding values, and restricted keys 

PDF field ids that begin that match the restricted keys pattern will not have data saved to the customer data object (the keys are reserved for pdf only fields and are saved to the document rather than the customer data) 

Text - saves string value as entered to pdf form field name 

Default field key - TEXT_WIDGET_${uuid} 

Dropdown - saves the selected option as a string to the pdf form field name 

COMBO_BOX_WIDGET_${uuid} 

Checkbox - saves the value entered in the Value* input when setting up the checkbox to the pdf form field name (as a string) CHECKBOX_WIDGET_${uuid} 

Radio - saves the value entered in the Value* input when setting up the radio options (as a string) 

RADIO_BUTTON_WIDGET_${uuid} 

Signature - no data is saved unless multi signer flow is active (if it is each owner signature can be found in the supporting documents pre signed get array) 

Agent Signature - no data saved 

Date Signed - no data saved 

Supported Under Document Types 

Generated Documents - these are automatically generated documents from the under system 

Generated PDF - the completed pdf under generated using customer data and signatures 

Esig Confirmation - a document with data that confirms a customers signature validity using the below attributes Record Id - a uuid that will be present on every page of the signed pdf. This is used to align an esig confirmation document to a completed pdf 

Last Updated - the date the customers data was last changed 

Application Name - name of the application that the customer filled out 

Pages - a count of all of the pdf pages 

Signer (or signers for multi signer flow) 

First Name - the signers first name 

Last Name - the signers last name 

DBA Name - the DBA name for customer 

Phone - contact phone number for the customer 

Email - the signers email 

Signature - copy of the customers electronic signature 

IP Address - IP address used at the time of signature 

Time Zone - Time zone where the signature took place 

Date Signed - Date the customer signed the pdf 

Supporting Documents - supporting documents from the form can be setup and added via the app editor Supported File Types - .jpg, .png, .pdf, .csv, .xls, .xlsx, .doc, and .docx

Max File Size - 10MB 

Under User Uploaded Documents - user uploaded documents added via the customer record Supported File Types - .pdf, .jpg, and .jpeg 

Max File Size - 10MB 

Under Response Model (visible in console network logs response) dataSent - this attribute will include all data that was sent to the destination endpoint 

destinationResponse - this attribute will include the response our endpoint received from the destination 

Integration Responses 

KYC 

same response as the raw tab in customer record 

KYB 

same response as the raw tab in customer record 

Twilio 

phone number used 

status message 

valid indicator that reflects whether or not the mfa check passed 

Hubspot 

response message explaining outcome with contact ID included 

Maps 

includes google fetch url to see location 

Softpull 

shows response message and includes a link to the softpull dashboard

‍

‍