"Address validation should be as pluggable as the connectors themselves."
The Problem Today
Even with built-in validators for phone numbers and email addresses, teams may need to apply custom validation rules (e.g. checking against a suppression list, verifying against an internal CRM). There is no extension point for this.
What We Are Building
An IAddressValidator abstraction that connectors invoke before send, and that applications can extend with custom implementations. A default composite validator chains built-in validators (E.164 normalization, email syntax/MX) with any application-registered custom validators. The chain is configurable per-connector via the DI registration API.
Benefits
- Custom validation rules (suppression lists, internal CRM checks) plug in alongside built-in validators
- Validation is always performed in a consistent, ordered, auditable chain
- Validation results carry structured details, not just pass/fail
The Problem Today
Even with built-in validators for phone numbers and email addresses, teams may need to apply custom validation rules (e.g. checking against a suppression list, verifying against an internal CRM). There is no extension point for this.
What We Are Building
An
IAddressValidatorabstraction that connectors invoke before send, and that applications can extend with custom implementations. A default composite validator chains built-in validators (E.164 normalization, email syntax/MX) with any application-registered custom validators. The chain is configurable per-connector via the DI registration API.Benefits