Overview of incidents in Cloud API

In the Cloud API base configuration, every supported incident type typically has five endpoints for the CRUD operations. For example, vehicle incidents has the following endpoints:

  • GET /claims/{claimId}/vehicle-incidents
  • POST /claims/{claimId}/vehicle-incidents
  • GET /claims/{claimId}/vehicle-incidents/{incidentId}
  • PATCH /claims/{claimId}/vehicle-incidents/{incidentId}
  • DELETE /claims/{claimId}/vehicle-incidents/{incidentId}

Insurers can also add custom subtypes to the hierarchy. For more information on how to generate endpoints for custom incident subtypes, see the Cloud API Developer Guide.

Minimum creation criteria for incidents

In the base configuration, there are no required fields for creating any type of incident. All fields are optional.

Inline damageables

An incident can also be associated with a damageable. A damageable is a data model entity that captures information about the covered object that is inherent to the object itself. For example, the base configuration has a Vehicle entity, which is a damageable used by VehicleIncident.

  • Information that is inherent to the vehicle, such as Make, Model, and Vin (Vehicle identification number) is stored on Vehicle.
  • Information about damage to the vehicle, such as the CollisionPoint and whether the AirbagsDeployed, is stored on the VehicleIncident.

When an incident has an associated damageable, you could theoretically have separate endpoints for the incident and the damageable. However, it is sometimes more convenient to embed the damageable information in the incident. When this is done, the damageable is referred to as an inline damageable. This is because the damageable information appears inline in the schema.

Incompatible incident types

You cannot create an incident whose type is incompatible with the policy type. For example, you cannot create a dwelling incident on a claim associated with a personal auto policy. If you attempt to do so, Cloud API responds with an error message similar to the following:

{
  "status": 404,
  "errorCode": "gw.api.rest.exceptions.NotFoundException",
  "userMessage": "No resource was found at path /claim/v1/claims/cc:34/dwelling-incidents"
}
Java

External user authorization for incidents

Cloud API supports authorization for different types of callers. One of the supported caller types is external users. An external user is a person who is known to the insurer but who is not listed as a user in the operational database. For ClaimCenter, one of the external user types is policyholders. They are users who want to interact with information about claims on their policies. For example, Ray Newton, who is a policyholder and wants to check on the status of a claim filed against his personal auto policy. For more information on external user authorization, see the Cloud API Developer Guide.

In the base configuration, external users have the ability to view and edit incident information on claims related to their policies. But, they can view and edit only the incidents that are related to a ClaimContact that is related to the policy with the role of Insured. They cannot view information about any other type of incident (such as a third-party incident).

For example, suppose Ray Newton files a claim for an accident involving himself and another driver, David Preston. The claim has two vehicle incidents: one for Ray Newton's vehicle and one for David Preston's vehicle.

  • Ray Newton can do the following.
    • View information about his vehicle incident, as this incident is related to himself, and he is related to the policy with the role of Insured.
    • Create new incidents (that may or may not be related to a ClaimContact that is an Insured on the policy).
  • Ray Newton cannot do the following
    • View or edit information about David Preston's vehicle incident.
    • View or edit information about any incidents he created that are not related to a ClaimContact that is an Insured on the policy.