Policy Snapshots and Coverage Summaries

Overview

Several common integration scenarios require certain views of the policy data in relation to a reference time. We support two views:

A “snapshot” of what the policy looked like as of a certain time. This will show what the policy would look like if you went back in time and examined a policy on that date. Snapshots have, for each policy entity, an array of characteristics objects to show coverage across time.

A “summary” of what the coverage is as of a certain time. This shows, assuming the policy is current, what the coverage was for a given date. It can also be extended to answer the broader question of “On date X, what did the policy show for coverage on date Y.” Summaries have, for each policy entity, at most one characteristics object, which shows the specific coverage for the given date.

API

Snapshots

The following endpoint can be used to retrieve a policy snapshot:

getPolicySnapshotUsingPOST¶

POST /policies/{policyLocator}/snapshot

Request:

Name	Position	Type	Required
policyLocator	path	string	required
request	body	PolicySnapshotRequest	required

Response: PolicySnapshotResponse

PolicySnapshotRequest¶

required
snapshotTimestamp timestamp

The snapshotTimestamp indicates the time at which you want the snapshot to be based. Policy transactions that were issued after this time will not be reflected in the response.

PolicySnapshotResponse¶

required
locator string
policyholderLocator string
productName string
snapshotTimestamp timestamp
characteristics [PolicyCharacteristicsResponse]
exposures [ExposureSnapshotResponse]

ExposureSnapshotResponse¶

required
locator string
name string
characteristics [ExposureCharacteristicsResponse]
perils [PerilSnapshotResponse]

PerilSnapshotResponse¶

required
locator string
name string
characteristics [PerilCharacteristicsResponse]
renewalGroup string

Coverage Summary

The following endpoint can be used to retrieve a policy coverage summary:

getPolicyCoverageAtCertainPointInTimeUsingPOST¶

POST /policies/{policyLocator}/coverageSummary

Request:

Name	Position	Type	Required
policyLocator	path	string	required
request	body	CoverageSummaryRequest	required

Response: PolicyCoverageSummaryResponse

CoverageSummaryRequest¶

required
coverageReferenceTimestamp timestamp

optional
policyHistoryTimestamp timestamp

The coverageReferenceTimestamp is the time to consider for coverage. For example, you could set this to a loss incident date.

The policyHistoryTimestamp indicates at what time was the policy considered authoritative for the given loss. For example, if there was an endorsement in July for a policy that had a May effective date, and you are considering a loss in June, you could set the history timestamp to reflect or exclude the effects of the July endorsement. By default it will be set to the current time, so that all issued transactions are reflected in the summary, even when examining a reference time in the past.

PolicyCoverageSummaryResponse¶

required
locator string
policyholderLocator string
productName string
coverageReferenceTimestamp timestamp
policyHistoryTimestamp timestamp
exposures [ExposureCoverageSummaryResponse]
documents [PolicyDocumentResponse]

optional
characteristics PolicyCharacteristicsResponse

ExposureCoverageSummaryResponse¶

required
locator string
name string
characteristics ExposureCharacteristicsResponse
perils [PerilCoverageSummaryResponse]

PerilCoverageSummaryResponse¶

required
locator string
name string
characteristics PerilCharacteristicsResponse
renewalGroup string

Policy Query Parameters

The entitiesAsOfTimestamp query parameter can be used to filter the following sub-entity arrays of the policy response.

policy_characteristics
exposure_characteristics
peril_characteristics
modifications
invoices
documents
fees

Filtering is generally based on matching elements whose endTimestamp is on or after the supplied entitiesAsOfTimestamp (i.e. >=).

The entities query parameter allows implementers to restrict filtering to a specific set of entities. The argument should be supplied as a comma-delimited list of one or more of the following:

characteristics
modifications
documents
invoices
fees

For example, supplying entities=modifications will ensure that only modifications have filtering applied; all other entities will be returned as usual. Setting entities=characteristics,modifications,documents,invoices,fees is functionally equivalent to omitting the entities parameter.

Note

By default, replaced characteristics (i.e. characteristics that have a replacedTimestamp) are filtered, regardless of the value of the entitiesAsOfTimestamp. This behavior can be overridden by also including the includeReplacedCharacteristics=true.