Can an external system ask Dynamics for a price?

Tier: Finance & Operations. Yes, and as of this year it is a supported, documented API rather than a custom service somebody wrote. It also has a published list of things it will not do, and a default that quietly returns less than you asked for.

The answer, with its date

The 2026 release wave 1 plan (ms.date 2026-07-28) lists Calculate prices for external systems through API with a check mark and Apr 26, 2026 against public preview, and a check mark and Jun 5, 2026 against general availability. By the plan's own legend — "Released features show the full date, including the date of release" — that is [GA].

The product documentation is Calculate prices for external systems through the pricing calculation API (ms.date 2026-03-24, updated_at 2026-03-27), which opens:

"The pricing calculation API enables external applications to retrieve accurate, real-time pricing and discount calculation results directly from Microsoft Dynamics 365 Supply Chain Management. By providing key input data, such as product and customer details, external systems can programmatically access calculated prices without creating sales orders."

Without creating sales orders is the part that changes architectures. The old pattern was to create a draft order, read the price off it, and delete it.

The prerequisites are a real gate

"- You must be running Microsoft Dynamics 365 Supply Chain Management version 10.0.47 or later. - Unified pricing management must be enabled in your environment."

That second line means chapter 6 is a prerequisite for this chapter. If your tenant still has the deprecated Pricing management module active, this API is not available to you, and no amount of integration work changes that.

What it will not do, in Microsoft's own table

Vendors rarely publish this column. This one does:

"Single-line price calculation per product" — "Multiline or cart-level discounts"
"Simple discounts" — "Basket pricing or promotion concurrency"
"Supply Chain Management pricing rules and pricing attributes" — "High-frequency or high-volume pricing calls"
"Quantity-based pricing (default quantity is 1)" — "E-commerce or storefront scenarios"
"Variant price ranges for product masters"

Read the second row against chapter 5. "Promotion concurrency" is not supported — so the five concurrency modes, the compounding model and the Always apply behaviour that decide what a real order line is discounted by are outside this API's scope as published. The number it returns is a price. It is not necessarily the number an order for the same goods would carry.

The default that returns a partial answer

This is the detail to take to whoever is building the integration:

"calculateSimpleDiscountOnly | boolean | Optional (defaults to true) | If set to true, only simple discounts are calculated. If set to false, the input is treated as a transaction for full calculation."

The default is the restricted one. An integration that omits the parameter — which is the natural thing to do with an optional field — gets simple discounts only. It will work, return sensible-looking money, and be quietly incomplete for any customer whose discounting is not simple.

Two more traps in the same section: "Parameter names are case-sensitive", and you must supply either productIds or priceLookupContext but "don't provide both in the same request", because doing so "can lead to conflicts or unexpected results".

What comes back is a breakdown, not a number

The response is genuinely useful for margin work. Per item it returns BasePrice, TradeAgreementPrice, AdjustedPrice, CustomerContextualPrice — "The final calculated price for the customer, including applicable discounts" — plus DiscountAmount, and two arrays: AttainablePriceLines, "An array of price lines that shows how the final price was determined, including the price method and origin", and DiscountLines, showing "the offer name, percentage, and effective amount".

Microsoft walks its own sample through, one step at a time:

"Base price – The system starts with the product's base price of $7.99, which comes from the released product definition."

"Trade agreement price – Because a trade agreement applies to this product, the system evaluates it and determines a trade agreement price of $30.00."

"Adjusted price – No price adjustments apply in this case, so the adjusted price remains $30.00."

"Discount calculation – The system identifies an applicable simple discount … The effective discount amount is $7.50."

"Customer contextual price – The final price for the customer is calculated as $30.00 − $7.50 = $22.50."

Note what the trade agreement did there: it took a base price of $7.99 to $30.00. Finance & Operations does not resolve toward the lowest number — a point chapter 8 develops, because Business Central's documented rule does exactly that.

Authentication is "OAuth 2.0 with Microsoft Entra ID (formerly Azure Active Directory)", and the external application must be registered "in both Microsoft Entra ID and Supply Chain Management".

When Microsoft tells you to use the other one

"This API is designed for low- to moderate-frequency pricing queries from system-to-system integrations. It isn't intended to replace the Dynamics 365 Commerce Scale Unit (CSU) pricing APIs. For high-scale, high-performance pricing scenarios—such as e-commerce storefronts, point-of-sale (POS), or product catalog browsing—Commerce Scale Unit APIs remain the recommended approach."

The named fits are quoting and contract validation, partner or ISV integrations, backend workflow services, and internal applications. If your use case is a storefront, this is the wrong API and Microsoft says so on the page.

How we build it: consume this, never rebuild it

Pricing & Discount Optimizer reads your rules and your history, decides which prices and discounts earn the most margin, and writes them back into the objects Dynamics executes — behind an approval step. Where a supported endpoint exists to read a calculated price, we call it rather than reimplement the calculation. That is the whole argument of this cluster in one sentence: the ERP calculates, and we choose what it calculates from.

A working demo exists; it is not off the shelf. We build it against your systems and your constraints on request, and we have no delivered pricing engagements — so this is a capability, not a report on somebody's business. We do not touch your ERP core.

Three things to check this week

Check your version against 10.0.47. Below it, this conversation is a roadmap item rather than an option.
Find every downstream system that holds a copy of your pricing rules. Each is a second source of truth that drifts from the first, silently, and this API is the supported way to retire the copy.
If an integration already calls this API, grep it for calculateSimpleDiscountOnly. If the parameter is absent, it is running with simple discounts only.

Chapter 5 is the concurrency this API's table excludes. Chapter 9 is what none of it decides.

About Cognilium Cognilium is the AI optimization layer for Dynamics 365 — complementary apps that optimize the pricing, inventory, warehouse and planning decisions your ERP manages but can't optimize. Built on Power Platform, Dataverse and Azure. https://cognilium.ai · https://www.linkedin.com/company/37180269/

Have a quoting system with its own copy of your pricing rules? Book a 15-minute call — we'll walk the decision and the model with you, on your data if you bring it. No deck.

Can an external system ask Dynamics for a price?