Data Validation

One of the most effective ways to prevent errors is to validate data before submitting an application to Alloy's API. If required fields are missing or incorrectly formatted, the Journey Application may enter a data_request_evaluation status — a state that requires additional resolution steps and creates friction in your onboarding flow.

Best Practice: A well-validated submission flow eliminates the need to build dedicated data_request_evaluation handling logic into your integration. Focus validation effort at the point of data collection rather than at the point of error remediation.

Preventing data_request_evaluation Statuses

  • Use the Get Journey Schema endpoint to identify required fields and their expected formats for your specific Journey. Required parameters vary based on which third-party services are configured in your workflows.
  • Add validation to your application form or data pipeline before submitting to Alloy. Common issues include missing required PII fields, incorrect date formats, and improperly structured address data.
  • Avoid submitting null or empty values for required fields, even if the field is technically optional for some scenarios.

PII Field Validation Reference

The table below covers validation guidelines for Alloy's most commonly used PII fields:

PII Element

Schema Field

Max Length

Accepted Format / Values

First Name

name_first

36

Last Name

name_last

48

Date of Birth

birth_date

10

ISO format: YYYY-MM-DD.

Recommend using a date picker to protect against improbable age values — many vendors throw errors in these cases.

Social Security Number

document_ssn

9

Must be a string comprised of 9 digits.

Address Line 1

addresses[].line_1

256

Address Line 2

addresses[].line_2

256

Address City

addresses[].city

256

Address State

addresses[].state

256

If US or CA address, must be a valid two-letter US or CA state/territory code.

Address Postal Code

addresses[].postal_code

30

Address Country Code

addresses[].country_code

2

Two-character ISO 3166-1 alpha-2 country code.

Address Type

addresses[].type

Persons: primary, previous, secondary, shipping, billing, service, military, other

Businesses: business_primary, business_secondary, business_previous

Phone Number

phone_number

Recommended in E.164 format, but not enforced. If not in E.164 when submitted, Alloy will attempt to convert to standard format before supplying to vendors.

Email Address

email_address

Must be a valid email format containing the @ symbol and cannot contain:

  • Leading and/or trailing dots
  • Consecutive dots

IP Address (v4)

ip_address_v4

Valid IPv4 format of X.X.X.X, where X is a decimal value between 0 and 255, separated by dots.

IP Address (v6)

ip_address_v6

Valid IPv6 format of Y:Y:Y:Y:Y:Y:Y:Y, where Y is any hexadecimal value between 0 and FFFF, separated by colons.

Note: In some cases, invalid data may pass Alloy's schema validation constraints, which can result in a service failure instead of Alloy stopping the application in a data_request_evaluation state. Data validation prior to app submission is still the best way to prevent this scenario.