Skip to main content

createProduct and updateProductprice when Billing Rules is active

Summary

For practices where Billing Rules is enabled, the API no longer requires price in ProductDataInput when calling createProduct or updateProduct. Pricing for those practices may be driven by billing rules instead of a fixed product price, so omitting price is valid when that matches your integration.

For practices without Billing Rules enabled, behavior is unchanged: createProduct continues to require price under the same rules as before, and updateProduct behaves as in previous releases. Other validation on these mutations (product type, lab fields, bookable duration, and so on) is unchanged.

This is scoped to the practice (whether Billing Rules is active for that practice), not to individual callers.

Integration guidance

Know your practice’s Billing Rules state. Whether price is required on createProduct depends on that setting. Integrations that serve both kinds of practices should:

  • Create: When Billing Rules is off, continue sending price as you do today. When Billing Rules is on, you may omit price if your product is priced via rules; otherwise send price when you still maintain a list price.
  • Update: When Billing Rules is on, you may omit price in productData if you are not changing it or if list price is not used for that product. When Billing Rules is off, updateProduct behaves as before this release (partial productData updates).
  • Responses: Product.price may still be present or absent depending on stored data and tax helpers; do not assume omitting price on write clears or sets a specific stored value unless you confirm behavior in your environment.

Mutations

  • createProduct(productData: ProductDataInput!) — With Billing Rules enabled for the practice, price is optional in productData. With Billing Rules disabled, validation matches previous releases (price required).
  • updateProduct(id: ID!, productData: ProductDataInput!) — With Billing Rules enabled, you may omit price in productData when appropriate. With Billing Rules disabled, overall mutation behavior for updates is unchanged from before this release.

All other fields and rules on ProductDataInput behave as documented in your schema snapshot.

If something breaks after this change

Problems often come from assuming price is always required on createProduct (strict client validation, OpenAPI or codegen “required” flags, or tests that always send a number). If you integrate with practices that use Billing Rules, relax local validation so price can be omitted when your product flow does not use a list price.

Check: refresh your schema or contract snapshot, adjust client-side required fields for createProduct when Billing Rules is on, and extend tests to cover both practice configurations.

See also

  • GraphQL input: ProductDataInput (field price) as used by createProduct and updateProduct in your published API reference.