API — can a bundle child's sell price be set per-job, or is it always re-derived from the bundle definition?

Developer API & SDK
1

What I’m building

An add-on that adds a material bundle to a job via the API. For a given job I want individual bundled lines to carry a custom sell price that differs from the bundle definition — without altering the underlying material or the shared bundle itself.

What I’m doing (API)

  1. POST /jobmaterialbundle.json — create the bundle on the job (job_uuid, material_bundle_uuid, sort_order).
  2. POST /jobmaterial.json for each child — job_material_bundle_uuid set to the new bundle, with a custom price / displayed_amount (and cost / displayed_cost).

The child lines are created with the custom values, and immediately after creation they are correct.

What happens

Shortly after the bundle is established, a server-side process re-derives each child line’s sell price from the bundle definition and overwrites what I sent. The same pass also re-sequences the child sort_orders. So:

  • Custom cost on a child line → retained. :white_check_mark:
  • Custom sell price on a child line → reverted to the bundle-definition value. :cross_mark:

Worked example

Bundle definition has two lines. I add the bundle to a job and send custom per-job values:

Child line Definition price Sent price Sent cost After SM8 recalc
Line A $45.00 $70.00 $20.00 price → $45.00 (reverted), cost → $20.00 (kept)
Line B $135.00 $160.00 $0.00 price → $135.00 (reverted), cost → $0.00 (kept)

Immediately after the POST, both lines read back at $70.00 / $160.00 as sent. A few seconds later (and again whenever the job is next opened natively), both sell prices snap back to the definition values of $45.00 / $135.00, while the costs remain as sent.

What I’ve tried (all revert)

  • Re-asserting the price with a follow-up PUT /jobmaterial/{uuid}.json immediately after create.
  • Re-asserting after a delay (to let the recalc finish first).
  • Creating a throwaway “decoy” child set first to absorb the recalc, then adding the real priced set into the established bundle, then deleting the decoy set.

In every case the price holds briefly, then the server resets it to the definition value. Cost always survives; only sell price is forced.

Questions

  1. Is there a supported way to set a per-job sell price on a line that belongs to a jobmaterialbundle via the API?
  2. Is bundle-child sell price always derived from the materialbundle definition (i.e., not independently settable on the job line), by design?
  3. If so, is there a field/flag to opt a given child line out of that recalc, or a recommended pattern for per-job bundle-line pricing?

Thanks!

2

Hi Miciah,

One-off changes to a bundle on a job are supported in the job card without changing the saved bundle or other jobs, so we wouldn’t conclude that bundle-child prices are always definition-derived.

For the API specifically, the reference documents price, displayed_amount and job_material_bundle_uuid, but the current documentation doesn’t establish a supported way to preserve your custom bundle-child sell prices, a recalculation opt-out flag, a recommended API workflow, or whether the reset you’ve described is by design. The documented job-card editing behaviour doesn’t establish an equivalent API workflow.

Please email support@servicem8.com with a sanitised request/response example and the before-and-after values so we can investigate the API behaviour privately, without including API keys or secrets.

Thanks,
Cody

3

Thanks Cody, email sent.