Skip to main content

​
Customer object

A customer represents a policy holder. The relationship between customers and policies is many-to-many: a customer can be on several policies, and a policy can have several customers, each with a business role. General
  • payment methods: a list of payment methods used by this customer.
  • invoices: a list of invoices issued to this customer.
Product specific information
  • custom fields: a list of product specific attributes. For more details check out custom fields.
  • aggregate fields: name, role and siret are properties of the customer itself rather than custom fields, and are sent as top-level properties of the edit call.

​
Working with customers over the API

A customer is not created on its own during new business: POST /customers?productId=... creates the policyholder together with a policy and a branch, and returns all three. Add further parties to an existing contract with POST /customers/policies/{policyId}, each with their business role. Fill a customer in with PATCH /customers/{customerId}. Company identity is the one part you do not control: supplying the SIRET triggers a registry lookup that overwrites the other company fields, so read the customer back rather than assuming your values persisted. See Company enrichment. GET /customers/{customerId}/relations lists the contracts a customer is attached to, and GET /policies/{policyId}/customers does the reverse — useful for finding which party is the payer, since that is the one whose payment method gates a signature request.

​
Customer statuses

A customer has a simple two-status lifecycle.