Changelog

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