This is the reference for what a public Nextdoor business record contains. Every percentage is a count over 741 distinct businesses across 5 cities and 12 categories, so the numbers describe real coverage rather than what the schema permits.
How to read this reference
A field with no percentage is always present. A field with one is present that often — and the rest of the time it is explicit null, never a missing key. That distinction is deliberate: a parser should never have to decide whether an absent key means empty, unsupported or broken.
Anything not listed here is not promised. That is a stronger statement than omitting it, and it is the honest position for a source that can change its markup without telling anybody.
Identity and categories
| Field | Filled | Notes |
|---|---|---|
name | always | As published by the business. |
slug | always | Nextdoor's own identifier in the URL. |
categories | 84.2% | Array. Businesses often sit in several of the 54 categories. |
description | 46.6% | Business self-description. Free text, length varies wildly. |
is_verified | always | Nextdoor's verification status. Boolean, never null. |
categories is the field to key on if you are building a directory, and the reason the 84.2% matters: one business in six arrives with no category at all, so a strictly category-partitioned dataset silently drops them.
Contact details
| Field | Filled | Notes |
|---|---|---|
phone_number | 93.9% | E.164 format. The best-covered contact channel by a wide margin. |
website_url | 77.2% | Often a Facebook or Instagram page rather than a domain. |
email | 62.6% | The binding constraint on any email-first campaign. |
Coverage compounds when you require two channels at once, which is the arithmetic behind sizing a lead list: a row set filtered to “has both phone and email” is around 60% of the rows you paid for.
Location
| Field | Filled | Notes |
|---|---|---|
address_full | conditional | Null across every address field when the business hid its address. |
address_city | always | Present even for hidden addresses. Use it to split city from trade area. |
address_postal_code | derived | Derived by the Actor: Nextdoor exposes no ZIP field in its schema. |
hide_address | always | True when the business chose privacy. Common for sole traders. |
source_city_slug | always | The city the row was discovered under, which is not always where it is. |
Trust and engagement signals
Four fields do the qualification work: is_verified, recommendations_count, neighbors_talking_count and recommendations_summary. The last of those is Nextdoor's own one-line synthesis of neighbor commentary, present on 47.4% of businesses, and it is the cheapest available proxy for reputation because it needs no recommendation rows at all.
hours_open_status sits here too at 57.4%, which is the field whose measured coverage fell furthest when the sample grew from 30 to 741.
Freshness metadata
Three fields describe the row rather than the business: from_cache says whether it was fetched or reused, fetched_at says when the data actually came off Nextdoor, and data_age_hours saves you the subtraction. Set maxCacheAgeDays: 0 to force a fresh read of everything.
Business contact details age slowly, so a week-old cached row is usually fine. The judgement is yours to make, which requires the data to tell you what it is — why that matters.
Nested recommendations
Each business row carries its recommendations inside it, and each of those carries kind, kind_confidence and kind_signals — because half the feed is not reviews at all. The nested rows deliberately omit scraped_at, _type, _warnings and business_id: the parent row already has all four, and the Recommendations view lifts nested keys to the top level, where two keys with the same name would silently overwrite each other.
What is not promised
- Star ratings. Nextdoor does not have them.
- Author identities beyond what Nextdoor publishes — a first name and last initial.
- Anything behind the login: private groups, member feeds, direct messages, keyword search.
- Any field not in the tables above. If it is not measured, it is not documented, and if it is not documented it should not be in your pipeline.
