Skip to main content

Salesbuildr Public API: Add a supported way to set a unit price per line when creating a quote

Feature Request

On the quote creation endpoint we only receive the productId and quantity. Add a way to add the sellable information fields (cost, price, markup) so users can manage that directly without relying on the catalog information.

Status: Done1 comment

Log in to comment and vote

Comments1

  • Copper Canary

    •

    Sep 9

    Thanks for shipping this — confirmed working on our tenant. A full override (price, originalPrice, cost, markup, term) came back exactly as sent, and omitted fields fall back to catalogue values: sending only price left cost and markup at catalogue, sending only cost left price and markup at catalogue. Sending only markup behaves differently — it recomputed price as cost x (1 + markup): cost 15, markup 0.5 returned price 22.50.

    One gap: the price object is absent from the published OpenAPI spec. CreateQuoteProductDto at /public-api/swagger documents only { id, quantity }, while the new setupCost/setupPrice on products are documented there.

    We generate our integration (an MCP server) from that spec, so an undocumented field cannot be picked up automatically — we would have to hand-maintain a spec that knowingly diverges from yours and re-check it on every release. Workable, but fragile. I reverse-engineered the shape below from validation errors; each key was accepted individually by the validator, but I have only exercised a few combinations, so please read it as observed behaviour rather than a complete contract:

    products[]: { id: string, quantity: number, price?: { price?: number, originalPrice?: number, cost?: number, markup?: number, term?: “one-time” | “week” | “quarter” | “month” | “6-month” | “year” | “2-year” | “3-year” | “4-year” | “5-year” | “10-year” | “trial” | “activation” } }

    Could you add the price object to the OpenAPI schema?

    Two questions about the semantics, both relevant to the accounting sync the release notes mention:

    1. When price or cost is set on its own, the returned markup stays at the catalogue value and then no longer relates the two: sending cost 20 for a product with catalogue price 56.17 and markup 0.4285714 returned all three unchanged apart from cost, though 20 × 1.4285714 = 28.57. Should consumers treat markup as an independent stored attribute, or derive it from price and cost?

    2. originalPrice defaults to the effective price rather than the catalogue price, so a line with only price set returns discount 0; setting originalPrice explicitly does produce a discount. Is that the intended behaviour?