Changelog

August 4, 2026

Fewer empty responses on person search

Three changes to how GET /v2/person/ and GET /v1/person/ narrow results substantially reduce the number of searches that return no results. None of them break the response shape or require callers to update existing integrations.

Automatic fuzzy-match fallback on zero results. When an exact-name search returns no results, the API now automatically retries the same request with fuzzy matching enabled (phonetic variants, nicknames, initials, typos) before returning. Exact-first precision is preserved for searches that succeed on the first pass; only zero-result searches trigger the fallback. The include_fuzzy_matching request parameter continues to work as documented — setting it to true still forces fuzzy matching on the first pass. Setting it to false (the default) no longer disables fuzzy matching outright; it disables it only for the first pass. See Fuzzy Matching for details.

New strict_match request parameter to opt out of the fallback. Callers whose use case treats "no results" as authoritative (for example, verifying a name genuinely does not exist in the dataset) can now set strict_match=true on the request to suppress the automatic fuzzy fallback. A zero-result exact query is returned as-is, without retrying. strict_match=true and include_fuzzy_matching=true are semantically contradictory; setting both on the same request returns HTTP 400.

Age filter no longer excludes records without a known DOB. When min_age or max_age is set, records for which no date of birth is on file are now included in results. The filter continues to exclude records whose known DOB falls outside the requested range — the behaviour change only affects records with a null age field. A strong name-and-address match now returns even when the person's age is unknown, where previously any age filter would drop that record. See Filter by Age Range.

August 3, 2026

age field on v2 person responses

Every record returned by GET /v2/person/ and GET /v2/person/{id} now includes an age field alongside date_of_birth:

{
  "id": "P19Xrg1Zr34",
  "name": "Jane Smith",
  "is_dead": false,
  "age": 68,
  "date_of_birth": "1957-12-22",
  "...": "..."
}

age is computed from date_of_birth at response time. When only a birth year is on file, age is a year-based approximation. When the DOB is missing or unparseable, age is null. Existing min_age / max_age request parameters filter by the same computed age; there is no behavior change to those parameters.

This change is purely additive: no existing field on Person Search or Person Details has changed type, nullability, or presence.

Response key order was also normalized on both endpoints so identity fields and match signals appear before the larger array fields; rely on key names, not position, when parsing.

June 18, 2026

result_metadata on v2 person search

Every record in a GET /v2/person/ response now carries a top-level result_metadata object summarizing each list and linking back to the canonical Person Details URL:

{
  "results": [
    {
      "id": "P19Xrg1Zr34",
      "name": "...",
      "phones": [...],
      "emails": [...],
      "historic_addresses": [...],
      "owned_properties": [...],
      "result_metadata": {
        "details_url": "/v2/person/P19Xrg1Zr34",
        "phones":             { "displayed": 3, "additional": 0 },
        "emails":             { "displayed": 1, "additional": 0 },
        "historic_addresses": { "displayed": 4, "additional": 0 },
        "owned_properties":   { "displayed": 0, "additional": 0 }
      }
    }
  ],
  "metadata": { ... }
}

displayed is the actual length of the list on this response; additional is the count linked to the person but not included. Today additional is always 0. A future release will tune Person Search to behave more like search: lean, ranked previews of each list focused on the items most likely to help a caller pick a match and decide whether to traverse for the full record. Payloads will be smaller and results easier to scan. Person Details (details_url) will always carry the full lists for callers who want everything; additional is the forward-compatible signal for how many more items live there. Safe to begin parsing now.

details_url is null for the rare result that arrives without a canonical Whitepages person ID (e.g., an unresolved phone-owner record); those records aren't part of the upcoming tuning.

This change is purely additive: no existing field on Person Search responses has changed type, nullability, or presence.

June 1, 2026

Address ID support on property details

GET /v2/property/{property_id} now accepts either a Whitepages property ID (R prefix) or an address ID (A prefix). Address IDs are resolved to the associated property before lookup, so you can look up property details directly from the address IDs found throughout other API responses.

Not every address ID has full property details, so lookups by address ID may return 404. These responses are not billed.

Billability changes

Billing rules have been simplified:

• 400 Bad Request responses are no longer billable on any endpoint.
• 404 Not Found responses on GET /v2/property/{property_id} are no longer billable, so you can optimistically look up property details by address ID.

2xx responses remain billable, as do 404 responses on all other endpoints. See Billing for the full policy. These changes apply to usage from June 1, 2026 onward — usage on or before May 31, 2026 is governed by the prior billing policy.

April 22, 2026

Pagination on v2 person search

The v2 person search endpoint now supports pagination. Use page (1–10, default 1) and page_size (1–15, default 15) to page through results. Every response now includes a metadata object:

{
  "results": [...],
  "metadata": {
    "result_count": 432,
    "page": 1,
    "page_size": 15
  }
}

result_count reflects the total number of matching records for your query. See the pagination guide for details.

April 2, 2026

Fuzzy name matching

Person search now accepts include_fuzzy_matching=true to broaden results with phonetic, nickname, and misspelling matching. See the fuzzy matching guide.

March 26, 2026

Email as a search parameter

Person search now accepts an email address alongside name, phone, and address.

March 25, 2026

Address field breakdown

Address objects in person responses now include discrete fields — line1, city, state, and zip — in addition to the formatted address string.

March 12, 2026

v2 person search and detail endpoints

The v2 person search (GET /v2/person/) and detail (GET /v2/person/{id}) endpoints are now available. v2 responses include enriched data:

• current_addresses and historic_addresses as separate lists
• match_score — a relevance and completeness score from 1–99
• matched_by — which input fields contributed to the match
• emails — email addresses with confidence scores

February 20, 2026

Webhooks for property deed events

Subscribe to real-time property deed events and receive HTTP POST notifications when deeds record in your target jurisdictions.

• POST /v1/webhooks — create a subscription
• GET /v1/webhooks — list subscriptions
• PUT /v1/webhooks/{id} — update a subscription
• DELETE /v1/webhooks/{id} — remove a subscription
• POST /v1/webhooks/{id}/test — send a test delivery

See the Webhook Quickstart for setup instructions.

February 18, 2026

Regions endpoint

GET /v1/regions/states and GET /v1/regions/states/{state}/counties return the list of supported states and counties, including a webhook_available field indicating which jurisdictions support deed event delivery.

February 11, 2026

Address confidence scores

Address objects in person responses now include a score field (0–100) indicating confidence in the address association with the person.

January 9, 2026

Search by geographic radius

Person search now accepts a radius parameter (in miles) alongside an address to restrict results to records within that distance. See the search by radius guide.

December 11, 2025

Age range filter

Person search accepts min_age and max_age parameters (18–65) to filter results to people within a specific age range.

December 9, 2025

Component name parameters

In addition to name, person search now accepts first_name, middle_name, and last_name as discrete parameters. name and the component parameters are mutually exclusive.

November 21, 2025

Historical locations

Person search accepts include_historical_locations=true to include past addresses in address matching. By default, only current addresses are considered.

Related