Wildfire Risk Insights API

The acronym API stands for Application Programming Interface and in practical terms is a format through which data is exchanged between two companies/endpoints. In simple terms, one company “calls” out for some information and the other responds to that request.

An API has request parameters or a clear definition of the data available. The user makes a call out to our system looking to pull that data set back into their system, using the returned data in whatever format they prefer. Every client pulls/receives the same data from Property Guardian. We do not yet provide bespoke data for individualized requests, we define the data set that’s available.

To get the optimal result a user is expected to provide the latitude and longitude of the property in question, as well as the street address. We will geocode the location off the street address using Google if latitude and longitude are not provided.

Each time we receive an API call we reach out to our best-in-class data providers to get the needed information and pass it back to the user in the same format every time. We don’t simply pass this data along, instead we aggregate and translate the data in our own unique way to optimize the API deliverable. This approach also adheres to the contractual parameters we’ve established with our handpicked data sources. It’s worth noting that each call that we initiate to our data sources generates fees that we must pay, as such during testing of a new integration we establish a QA endpoint to limit the incursion of these costs. 

Many insurance clients will use a third-party platform to manage their underwriting process, so Property Guardian must be able to integrate with these platforms. We would expect the third party to authenticate in the same way as the end user/client. And our relationship would be with the client using our data, not the third party that’s passing that data along. The third party defines where in the application the outreach to Property Guardian appears to the user. The rules around how/where our data appears is of no consequence to us.

Example: An integration between Property Guardian and the client might be a “call” button to our score and modifiers that is activated on an underwriter’s screen whenever Hazard Hub returns a score of 70 or higher for a specific location. 

No, only credentialed external users can access the Property Guardian URL. We have an established authentication method that is employed every time an external user makes a data request. An external user is assigned a specific set of credentials (email and password) and an access token that must be provided before each request for data can be processed. This methodology also allows us track usage levels per client.

Unlike other options that offer just a score, Property Guardian provides deeper insights. Property Guardian provides an overall score AND the breakdown of that score. Our output exposes the primary risk factors driving each of the four foundational scores (structure, parcel, community, and region) that ultimately shape our overall resiliency score. We also provide insight on secondary modifiers that help drive reinsurance costs.