Policy Snapshots and Coverage Summaries
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.
The following endpoint can be used to retrieve a policy snapshot:
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.
The following endpoint can be used to retrieve a policy coverage summary:
requiredcoverageReferenceTimestamp timestampoptionalpolicyHistoryTimestamp timestamp
coverageReferenceTimestamp is the time to consider for coverage. For example, you could set this to a loss incident date.
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.
Policy Query Parameters
entitiesAsOfTimestamp query parameter can be used to filter the following sub-entity arrays of the policy response.
Filtering is generally based on matching elements whose
endTimestamp is on or after the supplied
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:
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
By default, replaced characteristics (i.e. characteristics that have a
replacedTimestamp) are filtered, regardless of the value of the
This behavior can be overridden by also including the