A roofing restoration company’s business follows the weather. Hailstorms, tornadoes, and high winds each generate a predictable wave of damaged roofs and homeowners who need help. The company already had property data in HubSpot: addresses of homes where they’d done restoration work, organized as records the sales team could act on. What they didn’t have was a way to know, automatically and daily, which of those properties had been hit.

The manual version of that process—cross-referencing weather reports against a CRM list—doesn’t scale, and waiting for homeowners to call surrenders the window where proactive outreach converts. They needed the CRM to surface weather information on its own.

HubSpot doesn’t natively understand geography. It stores addresses, not coordinates, and has no concept of proximity or spatial relationships. It can’t answer “which of our properties are within five miles of last night’s storm?” without custom work.

Building that capability required external data ingestion, coordinate-based math, and a data model designed to hold the results where the sales team already works.

Architecture First: Two Custom Objects

Before writing a line of integration code, the data model needed to be right. Hypha created two custom objects in HubSpot.

The first, Property Locations, represents houses where the company has done or could do restoration work. The second, Weather Events, represents discrete extreme weather incidents—each with an event type, a date, and geographic coordinates. The association between these two objects is the central design decision. A sales rep opens a property record and sees, directly on the sidebar, every weather event that’s affected that area in the past 28 months. That view is built and maintained automatically, with no manual input.

Keeping the data inside HubSpot rather than an external database was a deliberate choice. The sales team already works in the CRM. Building the weather intelligence into the same system meant no new tool to adopt and no process change for the people making calls.

The Integration Pipeline

Once the architecture was in place, the integration handles five steps on an automated daily schedule.

How the Integration Pulls Daily Weather Data

Each day, the integration queries an external meteorological API for recent extreme weather events. Weather data providers don’t all offer the same event types, geographic coverage, or data quality—Hypha evaluated several before finding one reliable enough for the use case. That evaluation is a normal part of integration work. External API projects rarely connect cleanly to the first vendor you try.

Bridging Weather Coordinates and HubSpot Property Records

Weather events from the API return only latitude and longitude coordinates. Property records in HubSpot are stored as street addresses. These are two different representations of location, and the integration has to reconcile them before any matching can happen.

Drawing a Geographic Bounding Box Around Each Property

Using each property’s coordinates as a center point, the integration calculates the coordinate boundaries of an approximate area around the address. The implementation uses a rectangular bounding box rather than a true circle—computationally simpler and accurate enough for the use case. The coordinate math accounts for the curvature of the earth, which requires trigonometric corrections that aren’t obvious until you’re writing them.

Using HubSpot’s Search API to Find Affected Properties

With the bounding box calculated, the integration queries HubSpot’s search API for Property Location records whose coordinates fall inside those boundaries. This is HubSpot’s search infrastructure handling spatial logic it wasn’t originally designed for—the query treats coordinate values as filterable properties and returns matching records.

Creating the HubSpot Record Association

For each match, the integration creates an association between the Weather Event record and the Property Location record. That association surfaces on the property’s sidebar automatically, joining the accumulated history of prior events going back 28 months.

What the Sales Team Sees

From the rep’s perspective, the system is invisible until they need it. They open a property record and find the weather history already there: event type, date, and recency. The record reflects what’s actually happened to that property’s area, updated as of that morning.

The outreach call starts with specific information rather than a cold open. The rep knows a storm hit nearby before the homeowner has called. That shift—from reactive to proactive—is what the integration was built to enable, and it required no change to how the sales team uses the CRM.

The Pattern Behind the Project

Weather affecting properties is one instance of a broader architecture: external event data mapped to CRM records, associated automatically, surfaced where salespeople work. The same design applies anywhere a company tracks records that should respond to things happening outside the CRM—regulatory changes and the businesses they govern, permit activity and the properties it concerns, or market events and the portfolios they affect.

HubSpot’s custom object framework, combined with external API integrations and the search API’s ability to handle non-standard query logic, supports this kind of work without a separate data platform. The CRM can be the place where external event data lives and where teams act on it.

Building CRM Intelligence Around Real-World Events

If your CRM holds records that should respond to things happening outside it—weather events, regulatory changes, permitting activity—that’s an integration architecture conversation. We’ve built systems that pull external data into HubSpot, associate it to the right records automatically, and surface it where your team already works. Get in touch to talk through what that looks like for your use case.