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_evaluationhandling 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
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 |
| 36 | |
Last Name |
| 48 | |
Date of Birth |
| 10 | ISO format: Recommend using a date picker to protect against improbable age values — many vendors throw errors in these cases. |
Social Security Number |
| 9 | Must be a string comprised of 9 digits. |
Address Line 1 |
| 256 | |
Address Line 2 |
| 256 | |
Address City |
| 256 | |
Address State |
| 256 | If US or CA address, must be a valid two-letter US or CA state/territory code. |
Address Postal Code |
| 30 | |
Address Country Code |
| 2 | Two-character ISO 3166-1 alpha-2 country code. |
Address Type |
| Persons: Businesses: | |
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 |
| Must be a valid email format containing the @ symbol and cannot contain:
| |
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) |
| 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_evaluationstate. Data validation prior to app submission is still the best way to prevent this scenario.
Updated about 20 hours ago