Overview of policy contacts

In PolicyCenter, every job has an underlying policy. You can associate account contacts with this policy. For example, when a submission is created for an account, the default behavior is to associate the account's "primary insured" contact with the underlying policy as the "primary named insured". A contact associated with a policy is known as a policy contact. Policy contacts exist on policies that are unbound (such as a submission's underlying policy) and on policies that are bound.

In the PolicyCenter data model, there is no PolicyContact entity. Policy contacts are stored in the database using multiple entities:

  • The Contact entity
  • The AccountContact entity
  • One or more PolicyContactRole entities

In Cloud API, policy contacts are managed using a resource named PolicyContact. This resource gathers the information from multiple data model entities (Contact, AccountContact, and PolicyContactRole).

The following table summarizes the different base configuration /contact endpoints in each API and the resources used by those endpoints.

API Example endpoints Root resource type
Account

GET /account/v1/accounts/{accountId}/contacts

POST /account/v1/accounts/{accountId}/contacts

GET /account/v1/accounts/{accountId}/contacts/{contactId}

PATCH /account/v1/accounts/{accountId}/contacts/{contactId}

DELETE /account/v1/accounts/{accountId}/contacts/{contactId}

 AccountContact
Job

GET /job/v1/accounts/{accountId}/contacts

POST /job/v1/accounts/{accountId}/contacts

GET /job/v1/accounts/{accountId}/contacts/{contactId}

PATCH /job/v1/accounts/{accountId}/contacts/{contactId}

DELETE /job/v1/accounts/{accountId}/contacts/{contactId}

 PolicyContact
Policy

GET /policy/v1/accounts/{accountId}/contacts

GET /policy/v1/accounts/{accountId}/contacts/{contactId}

 PolicyContact

Policy contact roles

Some policy contact roles are LOB-agnostic. You can use these roles for contacts on any policy, regardless of the underlying LOB. In Cloud API, you can specify the following LOB-agnostic roles for a policy contact.

Role's display name Underlying policy role entity
Primary named insured PolicyPriNamedInsured
Additional named insured PolicyAddlNamedInsured

(used for any contact associated with a policy, but not displayed in the user interface)

 APDPolicyInvolvedParty

Some policy contact roles are LOB-specific. For example, in the base configuration Personal Auto product, adding a contact to a job's underlying policy using the POST /vehicle-drivers endpoint adds the "driver" role to the contact. The behavior of LOB-specific roles is dependent on how the product is modeled.

The remainder of this topic discusses how to manage policy contacts and the LOB-agnostic policy contact roles.