About
Why we’re building this.
The short version of why hail-path exists now, what’s honest about today, and what we’d love from early folks.
Why now
NOAA’s Storm Events data is public, but joining it to specific addresses at query-time is real engineering. Meanwhile the insurtech and property-services SaaS wave keeps expanding — Roofr, Jobber, Hippo, the Guidewire-adjacent tooling — all of them needing verifiable weather-event lookups. Enterprise providers (CoreLogic, Verisk) charge $10k+/year and require a sales call before they’ll quote.
There is no self-serve API in this shape today. hail-path is the version we wished existed when we tried to build on this data ourselves.
What’s honest about today
The verify endpoint is live and public — you can try it on the home page. Keys, the search endpoint, and metering are still in build. Everything on the pricing page is what we intend, not what you can buy today.
We’re building in public. The changelog is the ground-truth of what’s live vs. in-progress. If something on the marketing page ever gets ahead of that changelog, we screwed up — let us know.
What we’d love from early folks
If you’re building something that touches severe-weather verification — even loosely — we’d love a 15 minute call. In particular:
- Your integration shape. Where does an address-and-date-in / events-out call live in your product today, or where would it? What surfaces it?
- Your target p95. Is
/events/verifyin a user-facing request path, a background job, or a nightly batch? Different answers point at very different caching and pricing. - Your worst experience with existing vendors. What forced you to work around HailStrike / CoreLogic / Verisk? Sales cycle? Pricing model? API shape? Data quality? All useful.