One pricing API for every customer, contract and channel. Import your price lists, define the rules once, and resolve the right price, and the rule behind it, with one request.
Free plan, no credit card. Sample data included.
Contract prices, volume breaks and exceptions get copied into every system that shows a price, and every copy drifts.
Every contract price becomes another if-statement. Changing one customer's discount means a code change and a deploy.
The portal, the quoting tool and the ERP integration each re-implement contract prices and volume breaks, and drift apart.
One price in the portal, another on the quote, a third in the ERP, and nobody can say which one is right.
PriceRules is the one place prices are defined. The API is how every other system reads them.
Upload products, customers and pricing rules as CSV; an ERP export works. Every row is validated, and rejected rows come with a reason.
CSV import referenceContract prices, percentage discounts and amounts off for a customer or a customer group, a SKU or a product group, or everyone. 9 scopes decide which rule wins, most specific first; minimum quantities give volume breaks.
How rule matching worksYour portal, quoting tool or integration sends a customer code, SKUs and quantities with an API key. One request, up to 500 SKUs.
API referenceEach line comes back with the final unit price, the rule that matched and why it won, so no price is a mystery.
Resolve your first priceThis runs the same resolution function as the API, on a small sample workspace with a customer group and product groups. Rules are tried in 9 scopes, most specific first: this SKU before the product's group before all products, and on each, this customer before the customer's group before everyone. The first scope with a rule that applies sets the price. Within a scope, the highest qualifying minimum quantity wins, then the highest priority. The API response explains the winner the same way, in applied_rule and match_reason.
Rules in this sample workspace
Products: VLV-304 ($48.00, group VALVES), FAS-1001 ($24.00, group FASTENERS). Customer groups: ACME-BUILD in CONTRACTORS, NORDIC-FAB in no group.
Resolved unit price
$39.50$48.00
Rule: Acme volume price 100+
{
"customer_id": "ACME-BUILD",
"products": [
{
"sku": "VLV-304",
"quantity": 100
}
]
}{
"customer": {
"id": "ACME-BUILD",
"found": true,
"group": "CONTRACTORS"
},
"warnings": [],
"items": [
{
"product_group": "VALVES",
"final_price": 39.5,
"applied_rule": {
"name": "Acme volume price 100+",
"type": "fixed",
"value": 39.5,
"target": {
"customer": {
"type": "customer",
"code": "ACME-BUILD"
},
"product": {
"type": "sku",
"code": "VLV-304"
}
}
},
"match_reason": "MOST_SPECIFIC_RULE",
"pricing_summary": {
"savings": 8.5,
"message": "Customer saved 8.50 due to active pricing rules"
}
}
]
}Rule matching, price lookups, volume breaks and price-list imports: the parts every B2B project ends up writing, once more.
Your portal, quoting tool and ERP integration call the same endpoint, so their prices can't drift apart.
Learn moreTarget a rule at a customer or a customer group, a SKU or a product group, or everyone. The most specific scope with a rule that applies wins.
Learn moreColumn mapping, row-level validation, rejection reasons and safe retries for large files.
Learn moreUp to 500 SKUs per request, or up to 10 customers per bulk call.
Learn moreMinimum quantities create volume breaks; priorities settle ties deterministically.
Learn moreSee monthly resolutions in the app, with email alerts at 90% and 100% of your plan.
Learn moreA pricing change becomes one rule update instead of a code change and a deploy in every system, and there's one answer when someone asks what a customer pays. Estimate what that's worth with your own numbers.
An estimate from your inputs only: weekly hours × people × 48 working weeks gives today's workload; the share you expect to remove, times your hourly cost, gives the estimate. It isn't a benchmark or a guarantee, and it doesn't include your subscription or the development time to integrate the API.
Keep your ERP as the system of record. PriceRules holds the pricing rules and answers every system that needs a price.
Customer logs in, sees their contract prices. The portal asks the API instead of carrying its own price logic.
Sales builds a quote; every line is priced by the same rules the portal uses, volume breaks included.
Portal, quotes, ERP integration, marketplace feeds: every channel reads one pricing API, so a customer sees one price.
Already on a commerce platform? If it handles your pricing, great. PriceRules helps when the same prices also need to reach a quoting tool, ERP integration or custom portal.
Your data
Brought in as CSV files, or created in the app.
PriceRules
REST API
POST /api/v1/pricing/resolvePOST /api/v1/pricing/resolve/bulkYour applications
Your team calls the API from these systems.
Every plan includes the same engine, imports and API. Plans differ in capacity and API volume. Get 2 months free with yearly billing.
For trying PriceRules with your own data.
€0/ month
For small pricing teams putting a real pricing layer in place.
€29.99/ month
or €25 / month billed yearly2 months free
For established B2B teams pricing across more than one channel.
€79.99/ month
or €66.67 / month billed yearly2 months free
The official SDK wraps the pricing API: every response field typed, retries where they're safe, and a timeout. Any other language calls the REST API with one HTTPS POST.
npm install pricerulesimport { PriceRules } from "pricerules";
const pricerules = new PriceRules({ apiKey: process.env.PRICERULES_API_KEY });
const { data } = await pricerules.resolve({
customerId: "ACME-BUILD",
products: [{ sku: "VLV-304", quantity: 120 }],
});data.items[0]final_price 39.5applied_rule "Acme volume price 100+"
An API that stores your base prices and the rules that change them for specific customers, products and quantities, and returns the final price on request. Instead of each system keeping its own copy of contract prices and volume breaks, they all call the same endpoint.
Developers and agencies building custom B2B portals, quoting tools and multi-channel B2B systems for companies that sell the same catalog at different prices to different customers. Once it's integrated, the people who own pricing manage the rules in the app instead of asking for code changes.
Three rule types: a fixed unit price, a percentage discount off the product's base price, or a fixed amount off it (amount_off). Each rule targets specific customers, a customer group or everyone, and specific SKUs, a product group or all products, and can have a minimum quantity and a priority. Put customers and products in groups once, and one rule covers them all.
Several rules can apply to the same request. PriceRules checks rule scopes from most to least specific and stops at the first scope that produces a price. The product side decides first: rules for this SKU, then for the product's group, then for every product. At each of those, a rule for this customer comes before one for the customer's group, which comes before one for everyone. Without groups, that leaves four scopes: 1, 3, 7 and 9, in that order. Within a scope, the highest minimum quantity reached wins, then the highest priority. An unknown customer, or a request without a customer ID, only gets the scopes for everyone: 3, 6 and 9.
Yes. Any rule can have a start and an end date (whole days, both included, in your workspace's time zone). Enter next year's contract today: it is scheduled, takes over on its start date, and the old one stops after its last day, with no deploy and nobody changing prices at midnight. Requests can also send as_of to quote a future delivery date.
For each SKU and quantity: the base price, the final unit price, the rule that was applied (its name, type, value and minimum quantity) and a match_reason explaining why it won. It also tells you whether the customer was found (customer.found). An unknown or deleted customer code isn't an error: you still get prices, resolved as for an anonymous customer (only rules for everyone apply), with CUSTOMER_NOT_FOUND in warnings. A request can price up to 500 SKUs for one customer; a bulk request covers up to 10 customers.
No. Anything that can make an HTTPS request can ask PriceRules for a price. Already on a commerce platform? If it handles your pricing, great. PriceRules helps when the same prices also need to reach a quoting tool, ERP integration or custom portal.
Yes, for Node.js and TypeScript: npm install pricerules. It's a thin typed client for the resolve endpoints with no dependencies, retries where they're safe and a timeout, and it runs on Node 18 or later and edge runtimes such as Vercel Edge. From any other language, call the REST API directly: it's one HTTPS POST.
Not through a native connector today. You bring data in with CSV imports (for example, exports from your ERP) and your applications request prices from the REST API, which requires some development work on your side.
Existing products, customers and pricing rules are matched and updated with the new values, deleted products and customers are restored, and new rows are created. An import never deletes anything, and only new or restored records count toward your plan.
Only as long as an import needs them. Uploaded CSV files are deleted automatically 7 days after the import finishes, and error reports 14a file uploaded for an import that never started is deleted after 24 hours. Nothing is kept longer. The records you imported stay in your workspace, and your import history keeps each import's status, row counts and findings.
No. PriceRules sits alongside your existing systems as a pricing layer. Your ERP can stay the system of record; PriceRules answers the question "what does this customer pay for this SKU at this quantity?".
Sign in with Google or your work email to create a workspace on the Free plan. Onboarding can load sample data so you can resolve a price in the app before importing your own.
Create a free workspace, load the sample data or import your CSVs, and resolve your first price with curl in a few minutes.