Radar¶

Radar address verification with geocoding, residential/commercial classification, and place name resolution. Addresses are sent to the Radar Address Verification API as a single free-form query and come back normalized with coordinates, a verification status, a confidence tier, and a residential/commercial call. Choose it when you want lightweight verification and geocoding from a single API — it does not return USPS delivery-point (DPV) or vacancy data the way Smarty or Google Maps Platform do.

What It Provides¶

• Address validation strategy — RadarStrategy, registered with the strategy resolver as an AddressValidationStrategy implementation named radar when the extension activates (strategy family address_validation).
• Normalization — the validated address is rebuilt from Radar's response (address label, unit, city, state code, postal code, country code, county).
• Verification status — verified and partially_verified count as valid; verified maps to deliverable and undeliverable to undeliverable, otherwise unknown.
• Geocoding — latitude/longitude from the matched address.
• Residential/commercial classification — from Radar's result layer (postalAddress → residential, place → commercial), overridden by Radar's explicit residential flag when present, which also sets the RDI field.
• Place name resolution — Radar's place label for the address, when present.
• Confidence scoring — Radar's confidence tier (exact, interpolated, fallback) is mapped to a numeric score (1.0 / 0.8 / 0.5) in the result's provider metadata.
• Nothing else — the package contributes no webhook endpoints, Temporal workflows, schedules, admin pages, GraphQL fields, or event subscriptions.

Setup¶

1. Once installed (or dev-linked in development), the extension is discovered at startup; it can be enabled per channel from Settings > Extensions (per-channel activation via ChannelExtension).
2. Create a Radar account and get the server-side secret key (the manifest's install hint: "Create a Radar account and configure the server-side secret key").
3. Provide the key. The strategy factory reads secret_key from a config dict when one is supplied and otherwise falls back to the RADAR_SECRET_KEY environment variable — the strategy proxy registered at boot calls the factory with no config dict, so in the current code path the environment variable on the API service is what the validation call actually reads.
4. Select the provider for a channel by setting its Address Validation provider to radar — from Settings > Channels (edit a channel; saved through the updateChannel mutation), or the Settings > Geocoding & Geolocation page (which drives the configureChannelGeocoding GraphQL mutation); both require the settings.edit permission.
5. Checkout address validation only runs when the channel's Geocoding Enabled toggle is on — the checkout mutation reads geocoding_enabled before validating the shipping/billing addresses.
6. Test with the validateAddress GraphQL query, or the address-validation test panel on the Settings > Geocoding & Geolocation page ("Validate a structured address against configured providers").

Configuration Reference¶

Operational Notes¶

• Fail-open when unconfigured. With no secret key the strategy returns the input address unmodified and marked valid. The core GeolocationService is also fail-open: if the provider raises, checkout validation is skipped rather than blocking the order.
• Single free-form query. The structured address is joined into one comma-separated string and sent as the query parameter to api.radar.io/v1/addresses/validate, with the secret key in the Authorization header.
• Issues raised — no_result (error) when Radar returns no address match; unverified_address (warning) carrying Radar's verification status when the address is not verified/partially verified.
• No DPV or vacancy data. The result's DPV match code and vacancy flag are never populated by this provider — if checkout fraud rules depend on those fields, use Smarty or Google Maps Platform instead.
• Provider metadata on the result carries verification_status, confidence, confidence_score, and layer.
• Checkout capture. When the checkout mutation validates addresses, the result's address type, RDI, and place name are stored as verification metadata for fraud review and the order snapshot; a block validation mode on the channel rejects checkout on error-severity issues (default mode is warn_public).
• HTTP timeout is 10 seconds per API request.
• Alternative providers implementing the same strategy family: Smarty, Google Maps Platform, and ShipStation Validate Address.