Skip to main content

Contacts — payor flag, billing fields, and list filters

Summary​

The GraphQL API now exposes payor and billing-related fields on contacts, and lets you filter the contact list by payor and doctor status.

New on the Contact type (and when creating or updating a contact):

  • isPayor (Boolean)
  • paymentReference, billingDetails, invoiceRecipient, billingFrequency (String)

New on the contacts query:

  • Optional argument filters: ContactsQueryFilters, with optional isPayor and isDoctor (Boolean).

This is additive: existing queries and mutations behave as before. New arguments and fields are optional.

The schema documents that contacts(filters: …) is not available to FR practices. Integrations in those regions should not rely on this argument.

Integration guidance​

Reading contacts

  • Include the new fields in your selection set where you need payor or billing information. Omitting them returns null where there is no value.

Creating contacts

  • Pass the new createContact arguments only when your workflow collects them. All remain optional.

Updating contacts

  • Set fields inside updateContact → contactData (UpdateContactDataInput). Unset fields are typically left unchanged by your client according to your merge semantics; confirm behaviour against your generated client.

Listing contacts with filters

  • Use contacts → filters → isPayor and/or isDoctor when you need to restrict results. Omit filters for the previous listing behaviour (search, pagination, and options unchanged).
  • If you operate FR practices, do not depend on filters until product guidance confirms availability.

Queries​

The contacts query accepts optional filters: ContactsQueryFilters. Each filter field is optional; combine them as needed.

Types and inputs​

The Contact type and UpdateContactDataInput include the new fields listed in the summary.

Mutations​

createContact adds optional arguments for isPayor, paymentReference, billingDetails, invoiceRecipient, and billingFrequency.

updateContact accepts the same fields on contactData.

If something breaks after this change​

Problems are uncommon because the schema change is backward compatible. If your client fails at runtime, check for strict object mapping (unknown fields) or older generated clients that need regeneration after refreshing the schema.

Check: pull the latest schema, regenerate your GraphQL types and builders, and extend selection sets or inputs only where you adopt the new fields.

See also​