Property Data Prefill — integration & API spec

When: Tier 0.5 fallback geocode + the FIPS keys (state/county/tract) every downstream peril lookup joins on.

Why we call it: on its own, a coordinate pair is useless to a quote — no policy provision asks for latitude. We call this API because the two hazard services below (FEMA flood, CAL FIRE fire) can only be queried by point, not by address. The chain: address in → coordinates (x,y) out → those exact numbers become the geometry= parameter of the FEMA NFHL and CAL FIRE FHSZ calls → which return the flood zone and fire zone → which set the flood-coverage and wildfire-mitigation defaults in §5. The GEOID (FIPS state/county/tract codes strung together) is the second prize: it's the join key for tract-level datasets — e.g. joining tract-level wildfire-loss experience into territory rating — and COUNTY cross-checks Smarty's county_fips.

In plain English — what we send: the one-line property address as the customer typed it, plus two version pins (benchmark, vintage) so the same address always resolves the same way. What we get back: the government's official coordinates for that address and its census geography codes. We never show these to anyone — they exist purely to feed the next two calls on this page.

Docs: geocoding.geo.census.gov — Geocoding Services API · Auth: none · Cost: $0

When: every quote (Tier 1). SFHA_TF: "T" = Special Flood Hazard Area → the mandatory-flood-insurance trigger; FLD_ZONE + STATIC_BFE drive the §5 flood mapping.

Why we call it: this is where the geocoder's coordinates get spent. Coordinates in (the geometry= param) → one underwriting question answered: is this property in a federally mapped flood zone? SFHA_TF:"T" means a Special Flood Hazard Area — by federal rule, a mortgaged home there must carry flood insurance, so the quote flow has to surface flood coverage and the NFIP referral. FLD_ZONE + STATIC_BFE fill our normalized flood_zone field → §5 maps that to the flood provisions and the referral copy the customer sees.

In plain English — what we send: just a point — the longitude/latitude the geocoder produced — and the list of fields we want back. (The URL is the ArcGIS query format — the standard map-server software US government agencies run — which is why the CAL FIRE call below looks nearly identical.) What we get back: the flood-zone designation for that exact point. FLD_ZONE:"AE" = high-risk river/coastal flooding; SFHA_TF:"T" = the mandatory-flood-insurance flag; STATIC_BFE: 42.0 = how high (in feet) the water is expected to reach in the benchmark flood — the number elevation certificates argue about.

Docs: hazards.fema.gov — NFHL MapServer layer 28 · Auth: none · Cost: $0

When: every CA quote (Tier 1) — fills the normalized fire_zone field. Service verified live; this MapServer carries the 2007 SRA / 2011 LRA vintage — the 2024–25 adopted zones publish via the CAL FIRE FHSZ Hub with the same HAZ_CLASS vocabulary.

Why we call it: the second place the geocoder's coordinates get spent — same pattern as FEMA, this time for wildfire. Coordinates in → HAZ_CLASS ("Moderate" / "High" / "Very High") out → that value fills our normalized fire_zone field → §5 turns it into the wildfire-mitigation options (defensible-space credits, roof-class requirements), and it cross-checks our own climate cat-model's score. SRA tells us whether the state or the local fire department is responsible for that land — which decides which zone-map vintage applies.

In plain English — what we send: the geocoder's coordinates again, asking for three hazard fields and no map shapes (returnGeometry=false keeps the response tiny and fast). What we get back: California's official fire-hazard severity rating for that point. "Very High" is the rating that triggers mitigation requirements — and for some carriers, declination; for us it triggers the mitigation-credit options in §5.

Docs: services.gis.ca.gov — Fire_Severity_Zones MapServer · Auth: none · Cost: $0

When: Tier 0.5, before any money is spent — CASS-certified normalization (USPS's stamp that the address comes back in its one official spelling) so the cache key can never split on "Dr" vs "Drive". Bonus underwriting signals for free: rdi (residential/commercial) and dpv_vacant.

Why this is the FIRST call in the chain: every later vendor — and our own cache (the database where Groundwork stores every vendor answer it has already paid for) — keys off the address string. If "1842 Skyline Dr" and "1842 Skyline Drive" looked like different properties, we'd buy the same data twice and split one property's history in two. Smarty returns the single USPS-canonical form → that string becomes the cache key → Regrid turns it into an APN / property_id. Its latitude/longitude can replace the Census geocoder call entirely (one less hop), and rdi / dpv_vacant are free eligibility gates: a commercial or vacant "home" fails homeowner eligibility before we spend a cent on paid vendors.

In plain English — what we send: the raw address parts the customer typed, plus our account keypair. What we get back: the same address the way USPS writes it (delivery_line_1), its ZIP+4, coordinates, the county FIPS code (the government's numeric ID for the county), and two cheap red flags — rdi:"Commercial" (this isn't a residence) and dpv_vacant:"Y" (USPS says nobody lives there). Either flag stops the prefill chain before any paid call happens.

Docs: smarty.com/docs — US Street Address API · Auth: auth-id/auth-token keypair · Pricing: published at smarty.com/pricing

When: first hop on every cache miss (a property we haven't bought data for yet) — address → APN mints property_id. Full schema is public; building fields (yearbuilt, footprint) are in standard tiers.

Why we call it: the Assessor Parcel Number (parcelnumb) is the missing primary key. Addresses change spelling and formatting; the APN is how the county itself identifies the land. Clean address (from Smarty) in → APN out → we mint our internal property_id from it → every later vendor result, cache entry, and refresh event hangs off that one id — one id means one paid data history per property, the dedupe that makes the §2 cache savings real. The bonus characteristics (yearbuilt, building sqft, land use) give the quote form its first real defaults, and landval/improvval sanity-check the replacement-cost estimate in Class E.

In plain English — what we send: the normalized address (or a map point, or an APN directly if we already have one) plus our token. What we get back: the county's parcel record — the APN, what's built on it (year, style, square footage, footprint), how it's zoned, the lot size, and the assessor's land/improvement values. usedesc:"Single Family Residential" confirms we're even quoting the right product.

Docs: support.regrid.com — Parcel API endpoints · full parcel schema · Auth: token query param · Pricing: plans behind signup, free 30-day trial

Decision lens: the "cheaper and good enough for presale" candidate — broad national fill at ~$0.10–0.50. Construction/roof attributes exist in deeper packages but aren't in the public sample — verify fill-rate in the §2 bake-off before relying on them for rating.

Why we call it: the presale characteristics fill. Address in → tax-record profile out: yearbuilt, livingsize, beds/baths become the quote-form defaults the customer confirms instead of types, and they're the inputs the replacement-cost estimator (Class E) needs to produce a Coverage A number. The apn/fips echoed back lets us double-check Regrid's parcel match before caching anything under the wrong property_id.

In plain English — what we send: the street line and city/state of the property, with our API key in a header. What we get back: a profile assembled from county tax records — what kind of building it is, when it was built, its living area and room counts, lot size, and an estimated market value. Cheap (~$0.10–0.50) and nationally broad, but tax records can lag reality — which is exactly why the §2 bake-off measures fill-rate before we trust these fields for rating.

Docs: api.developer.attomdata.com/docs (interactive, free trial key) · Auth: apikey header · Pricing: subscription tiers, not public

Decision lens: the insurance-grade characteristics candidate for formal_quote — carriers are the customer base. US property/CLIP API schema requires contract; its MLS product (Trestle — MLS is the real-estate listing system agents use) and AU (automated-underwriting) portal are public, which shows the integration style.

Why we'd call it: the formal-quote upgrade over ATTOM. The CLIP id plays the same role as Regrid's APN — a universal property key — but the payload is the insurance-grade set: construction class, roof type/material, plumbing/electrical age. Those are exactly the fields the 360Value/RCT replacement-cost call (Class E) consumes and the rating engine prices by. Address or CLIP in → carrier-grade characteristics out → Coverage A default + construction rating factors.

In plain English — what we send (under contract): an OAuth login, then a property lookup by address or CLIP id. What we get back: the property's physical build sheet at the accuracy level carriers rate on. Exact field names are NDA'd — so the right read of this card is "this is the vendor conversation to have when the §2 bake-off shows ATTOM's gaps in construction/roof fields cost more in Coverage A error than Cotality's per-call premium," not "integrate today."

Portal: developer.corelogic.com (marketing shell; access via sales) · Public reference of style: Trestle docs · Auth: OAuth 2.0 · Pricing: contract

When: the natural §2 bake-off challenger to Regrid — full OpenAPI spec is readable today; evaluation keys on registration. Also wraps FEMA NFHL as a convenience API.

Why we'd call it: the bake-off challenger to Regrid for the same job in the chain — address → parcel/APN → property_id. Keeping two interchangeable vendors for the chain's first paid hop is deliberate: it keeps per-call pricing honest and gives us a failover if one has an outage. Its FEMA-NFHL convenience wrapper also means one vendor could collapse two calls (parcel + flood zone) into one bill.

In plain English — what we send: a free-text address (or a FIPS+APN pair — county number plus parcel number — or a map point) with an API key header. What we get back: the parcel identified (parcelApn, fips), where it sits, how the land is used, assessed values, and an occupancy flag — OWNER_OCCUPIED matters because owner-occupied vs rented changes which policy form even applies.

Docs: lightbox.document360.io — Parcels · Auth: x-api-key header · Pricing: not public

When: every formal quote — PPC is referenced directly in filed rates, so this is the hard-to-substitute call. Endpoint, params and auth are publicly documented; the response schema ships under contract.

Why we call it: PPC is the fire-protection grade (1 = best, 10 = worst) that filed rates reference by name — the approved rating table literally has a PPC column, so no PPC means no priceable formal quote. Address in → split class out (e.g. 4/4X) → the rating engine reads it directly. It's also the one field on this page we can't substitute with our own model, because the regulator approved our rates as filed against PPC.

In plain English — what we send: street/city/state/zip plus Verisk credentials (a token and org ids). What we get back: the community's fire-protection grade for this address. "4/4X" decodes as: a fire station within 5 road-miles earns class 4; the X suffix says the home is more than 1,000 ft from a hydrant — water has to be trucked in, so it prices worse. respondingStation.distanceMiles is the underlying driver an underwriter can verify on a map.

Docs: prometrixapi.iso.com/docs — PPC by Address · split-class explainer · Auth: Verisk STS token (their central login service) + branch id · Pricing: contract

Decision lens: the only imagery-AI vendor with a fully public field-level schema — and its supplementals (wildfireScore, defensibleSpace) overlap Class F, so one subscription can cover two catalog rows. Credit/subscription model favors portfolio sweeps + renewal refresh over per-quote calls.

Why we call it: aerial-photo AI sees what tax records can't — the current physical condition of the roof and the vegetation around it. Address in → parcel-clipped AI features out → roofSpotlightIndex + roof material feed the §5 loss-settlement options (a worn roof gets actual-cash-value settlement terms, not full replacement-cost), and defensibleSpace/wildfireScore overlap Class F — so one Nearmap subscription can double as the wildfire-score source.

In plain English — what we send: the address, which "packs" of AI features we want (roof condition, vegetation), and parcelMode=true so results are clipped to this parcel — not the neighbor's roof. What we get back: machine-read facts from the latest aerial survey (surveyDate says how fresh): what the roof is made of (Tile, 82% of the area), its condition score (roofSpotlightIndex: 0.71 — closer to 1 is healthier), and how much burnable vegetation sits within striking distance of the structure.

Docs: developer.nearmap.com — AI Feature API · Auth: apikey · Pricing: subscription + AI export credits, list not public

When: the conditional Tier 3 quote-time call. API reference is customer-gated, but the attribute vocabulary is public via product pages and rate filings — the 5-band roof condition scale below is what §5 maps to loss-settlement options.

Why we'd call it: the conditional Tier-3 call — fired only when the cached roof data is stale or the cat-model score is borderline, because every call costs real money. Address in → graded roof verdict out → roof_condition_rating is the field §5 maps to loss-settlement options, and the reason_codes (tarp, patching, standing water) are human-readable evidence an underwriter can act on — and that we can show the customer to explain a referral (routing the quote to a human underwriter instead of auto-approving it).

In plain English — what we send (under contract): an address or coordinates, choosing which analytic modules to run. What we get back: a graded roof verdict — "Fair" on a Severe→Excellent scale — plus the visible reasons behind the grade (streaking, patching), and yard-level liability flags like a pool or trampoline, which trigger liability questions in the quote flow.

Vocabulary: Roof Condition Rating v5 · reason codes · Auth/pricing: contract

Decision lens: an ordered report, not a real-time lookup — $20–50 and hours, not milliseconds. That shape alone tells the stakeholder where it belongs: claims scope-of-repair and targeted inspections, never quote-time prefill.

Why we'd call it: this isn't prefill at all — it's how a claims adjuster gets exact roof measurements (area in squares, pitch, every facet edge) to price a repair without climbing the roof. The chain runs from the other direction: claim filed → order placed → measured report hours later → scope-of-repair estimate. Its presence on this page is a scoping decision made visible: $20–50 per report and hour-scale latency disqualify it from quote-time.

In plain English — what we send: an order — the property address plus product codes saying which report type and delivery speed we're buying. What we get back, immediately: just order and report IDs (a receipt). The actual deliverable — a measured roof report with area in roofing squares, pitch, and edge lengths — is fetched later through the status/report endpoints once their measurement pipeline finishes.

Docs: developer.eagleview.com (a JavaScript single-page app — open it in a browser; public Postman workspace exists) · Auth: OAuth2 (24 h token) · Pricing: contract

When: formal_quote only, under permissible purpose. Docs require an approved portal application; the report contents are well-documented by regulators (7-year claim window).

Why we call it: past claims are the strongest single predictor of future claims — and the one thing a customer can't tell us reliably. Name + address in → 7 years of claims on both the property and the person out → §5's underwriting referral rules fire on loss count/type/amount (e.g. a prior water loss routes the quote to water-damage review instead of straight-through bind). The FCRA strings are the cost: only at formal quote, only with certified permissible purpose, and a declination based on it triggers adverse-action notice duties.

In plain English — what we send (under contract): who is asking to be insured (name, date of birth) and which property, plus a certified statement of why we're allowed to ask (insurance underwriting). What we get back: every reported claim in the last 7 years — when, what kind (WATER), how much was paid, which carrier. A clean report sails through; an $18,400 water claim two years ago routes the quote to an underwriter.

Product: risk.lexisnexis.com — C.L.U.E. Property · Report contents per Wisconsin insurance regulator's (WI OCI) consumer FAQ · Auth: OAuth via approved dev-portal account · Pricing: contract (~$2–5 indicative)

When: formal_quote; the one class where call-both (with C.L.U.E.) is justifiable on high-value risks — the two claim databases overlap but not 100%. Note how little the request needs: names + address are the only mandatory fields.

Why we call it: Verisk's competing claims database for the identical job as C.L.U.E. — same chain position (name + address → 7-year loss history → §5 referral rules). It earns its own card because the two databases don't fully overlap: different carriers contribute to each, so on high-value risks calling both is the rare justified call-all. Its loss-type codes (WBKP water backup vs SBKP sewer backup) are also more granular than C.L.U.E.'s categories — granularity the referral rules can use directly.

In plain English — what we send: first/last name and the property address, with Verisk's bearer token and org headers — nothing else is mandatory. What we get back: the claim list with coded loss types and statuses. status:"CWP" means closed without payment — a claim that cost the carrier nothing still counts as claims history, which is exactly the nuance worth flagging for a junior underwriter.

Docs: gateway.verisk.com — A-PLUS Claims v4 (schemas via client services) · Auth: Bearer + OrgId/ShipId · Pricing: contract (~$2–5 indicative)

When: after Class B/C fields land (the estimate is only as good as its input characteristics). Pick one, pin its version with every estimate — the figure backs Coverage A and must be reproducible at claim time. RCT's SOAP surface (ExpressLync; SOAP is an older XML-based API style still common in insurance back-ends) is visible publicly; both schemas are contract-only.

Why we call it: Coverage A — the biggest number on the policy — defaults to replacement cost, not market value, and this is the call that computes it. It consumes the upstream Class B/C characteristics (sqft, quality grade, roof material, stories) → returns reconstructionCost → §5 sets the Coverage A default from it. That's why it must run after characteristics land: garbage square footage in, garbage Coverage A out. Pinning estimatorVersion with every estimate keeps the number reproducible at claim time, years later.

In plain English — what we send: the property's build facts — square footage, construction quality, roof material, stories (360Value can even start from just the address and prefill the rest itself). What we get back: what it would cost to rebuild this exact home today — $487,000 — assembled from local material and labor costs across 431 US cost regions, itemized by component, with a version stamp we store alongside the policy.

Products: verisk.com — 360Value Personal · rct.corelogic.com · Auth/pricing: contract (~$1–3 indicative)

When: the incumbent score many state filings reference — the challenger comparison for our own cat-model. A free data sample exists on AWS Marketplace for the §2 bake-off.

Why we call it: two reasons. As a rating input where our filing references it — and as the benchmark our own climate cat-model must beat in the §2 bake-off (same property set, FireLine score vs our score vs actual losses). Address or lat/lng in → 0–30 hazard score with its drivers (fuel, slope, road access) out → rating factor + the comparison row in our model-evaluation table. If our model wins that comparison, FireLine drops from per-quote spend to an annual audit sample — a vendor line item the model can delete.

In plain English — what we send: the address (or coordinates) with Verisk auth. What we get back: a 0–30 wildfire hazard score with what's driving it — how much there is to burn (fuel), how fast fire climbs toward the home (slope), and whether fire trucks can actually reach it (road access). A 23 / "extreme" pushes the property into mitigation-required territory.

Docs: gateway.verisk.com — FireLine personal lines · Auth: Bearer + org/ship ids · Pricing: contract (~$0.50–2 indicative)

When: the ML challenger A/B against FireLine. Schema is NDA, but the model structure is public via regulator filings (adopted for rating in 6+ states): L1 = probability the property falls inside a fire perimeter; L2 = probability of destruction given fire.

Why we'd call it: the ML challenger to FireLine — and a different kind of answer. Not "how hazardous is the area" but two probabilities: L1 = chance the property ends up inside a fire perimeter, L2 = chance it's destroyed given fire reaches it. L2 is where mitigation shows up — clearing defensible space moves L2, not L1 — which is exactly the structure §5's mitigation-credit options need. Adopted in 6+ state rate filings, so using it in rating is a regulator-trodden path.

In plain English — what we send (under contract): the address. What we get back: the two probabilities and the property-level factors driving them (roof, defensible space, vegetation, slope, fire-station proximity). The L1/L2 split is the actionable part: a customer can't move their house out of L1, but clearing brush moves L2 — and the premium credit moves with it.

Product: zesty.ai — Z-FIRE · Factor list per WA OIC presentation · Auth/pricing: contract

When: the §4 refresh feed — a re-roof permit is the cheapest possible roof-age update (~$0.10–0.50/property/yr watchlist vs a $2 imagery call). Fully public, self-serve API key. (BuildFax, the Verisk-owned alternative, is contract-gated with no public reference.)

Why we call it: prefilled data decays — a 2019 roof-condition score is fiction after a 2024 re-roof. Permits are the cheapest change signal in existence: counties publish them, and a roof_replacement permit on our parcel means the cached roof facts must refresh. Address → geo_id → permit feed → the §4 refresh triggers fire (re-pull imagery, recompute replacement cost) → renewal re-rates accurately in either direction: credit the new roof, catch the unpermitted addition.

In plain English — what we send: first the address (to get Shovels' geo_id for the parcel), then a permit search on that id bounded by date range, with our self-serve API key. What we get back: the permit record — what work was done ("Tear-off re-roof, Class A comp shingle"), whether it was finished and inspected (status:"final", inspection_pass_rate: 1.0), when, and its dollar value. A finaled $24,500 roofing permit is better evidence of a new roof than the homeowner's say-so.

Docs: docs.shovels.ai — permits search · Auth: X-API-Key, self-serve · Pricing: published plans