Introduction

To build a custom integration for AddressValidation, implement a set of well-defined, single-responsibility contracts. The framework handles orchestration — the validation pipeline, HTTP resilience, and access token caching — so you only supply provider-specific logic.

Steps

Follow these steps to build a custom integration:

1. Data Models: define the public-facing request type and the provider's JSON DTO classes
2. Mappers: translate between the request model and the provider DTO, and map the provider response to IAddressValidationResponse
3. Authentication: request, cache, and refresh an access token from the provider (OAuth 2.0 only)
4. Validation Client: call the provider's address validation endpoint and bridge the public request to the client
5. Validators: validate the request before sending and the response after receiving
6. Registering Services: wire the pipeline components together and register all components with the DI container
7. Batch Validation (optional): Batch Mappers, Batch Validation Client, and Batch Validators

Note

Step 3 is only required when the provider uses OAuth 2.0 bearer tokens. Providers that authenticate via static API keys, query string parameters, or other schemes can skip that step and omit the BearerTokenDelegatingHandler<TClient> from the HTTP client pipeline during service registration.

Note

Step 7 only applies when the provider's API natively supports validating multiple addresses in a single call. It adds three components alongside the ones built in steps 1–6 and wires them up in the Batch Validation Service section of service registration.