Vepler logo
v5.15.0

Postcode conflicts and unconfirmed flats held for review in address matching

Address resolve and cleanse hold a postcode disagreement or an unconfirmed flat back for review, so a flat-level input is not auto-accepted against a building-level record.

Changed

  • POST /v1/address/resolve and POST /v1/address/cleanse hold a match back for review when the address text you send embeds a full postcode and it differs from the full postcode on the matched record. The postcode is read from the address text itself, so the check applies when that text carries exactly one full postcode. The match comes back no better than grade C, with action set to review, isReliable false, and a reason naming the conflict.
  • The same review outcome applies when your input names a flat or another sub-building and the best match is only building level, so a flat-level input is never auto-accepted against a building-level record. Read reason rather than the grade alone to tell the two cases apart.
  • Read the assessment from result.matchQuality on POST /v1/address/resolve, present whenever the request resolved to one or more premises, and from quality on each entry of results on POST /v1/address/cleanse, present on each address that matched. Both carry grade, one of A, B, C, D or F, an action of accept, review or reject, the boolean isReliable, and a human-readable reason. On resolve the same object also carries unambiguityScore and a factors breakdown, so you can apply your own policy from the individual signals.
  • This is a stricter assessment, so an integration that auto-accepts on an action of accept will see more review outcomes on postcode-mismatched and flat-level inputs. Route those to a reconciliation step, or apply your own acceptance policy from grade and reason.

Affected endpoints