Features

The pricing rules engine, imports and API behind consistent B2B prices.

Each capability below starts with a problem B2B pricing teams run into, shows how PriceRules handles it, and links to the documentation that explains the details.

Pricing rules engine

Customer-specific prices and volume breaks as rules, not spreadsheet tabs.

The problem: Contract prices, account discounts and quantity breaks are kept in per-customer spreadsheets or hard-coded in the storefront, so changing one means hunting down every copy.
How PriceRules handles it: Every price adjustment is a rule: a fixed unit price or a percentage discount off the base price, scoped to a customer, a SKU, both, or everyone. Rules can require a minimum quantity and carry a priority.

The most specific scope that qualifies wins: customer + SKU, then SKU, then customer, then all customers.
Within a scope, the highest qualifying minimum quantity wins — that's how volume tiers work.
Priorities, then the lowest price, settle any remaining tie, so the same input always gets the same price.
Rules can be paused without being deleted; inactive rules are never applied.

Why it matters: One rule change updates the price everywhere it's requested, and anyone can see which rule produced a price.

How customer-specific rule matching works

Pricing rules · sample workspace

Rule	Customer	SKU	Effect
Acme volume price 100+	ACME-BUILD	VLV-304	fixed $39.50, 100+ units
Acme contract price	ACME-BUILD	VLV-304	fixed $42.00
Nordic account discount	NORDIC-FAB	All	10% off
Trade discount	All	All	5% off

For ACME-BUILD buying 120 × VLV-304 (base $48.00), the 100+ volume price applies: $39.50 per unit.

CSV imports & validation

Bring existing price lists in without cleaning them by hand first.

The problem: Pricing data lives in exports and spreadsheets with inconsistent headers, decimal formats and the odd typo — and a bad row shouldn't silently produce a bad price.
How PriceRules handles it: Import products, customers and pricing rules from CSV. PriceRules suggests a column mapping, validates every row and reports each rejected row with a specific reason, while the valid rows are saved.

Accepts common number formats such as 12.5, 12,5, 1,750.00 and 1.750,00.
Rules must reference existing customers and SKUs, so typos are caught instead of creating rules that never match.
Large files are processed in the background in batches; a failed import can be retried without saving rows twice.
Plan capacity is checked before rows are saved, so an import can't push you past your limits.

Why it matters: You can move an existing spreadsheet-driven process into PriceRules in an afternoon and know exactly which rows need fixing.

Read the CSV import reference

Import validation · illustrative result

1,240

Rows read

1,237

Valid

Rejected

Row 4SKU: Product not found
Row 9VALUE: Invalid
Row 12PRICING_RULE: Duplicate in import

Messages shown are real validation messages from the import reference; the counts are an example.

Pricing API

One REST API for single and bulk price resolution.

The problem: Each application that shows or charges a price needs the customer's price — and reimplementing the rules in every codebase is how they drift apart.
How PriceRules handles it: Send a customer code and a list of SKUs with quantities. PriceRules returns the final unit price for each line, the rule that was applied, why it matched, and how much of your monthly quota remains.

Single resolution: up to 500 SKUs for one customer per request.
Bulk resolution: up to 10 customers per request, each with up to 500 SKUs.
A best_price mode returns the lowest qualifying price instead of the most specific rule.
Authenticated with workspace API keys; documented error codes for invalid input, unknown SKUs, rate limits and quota.

Why it matters: Developers integrate once; pricing changes after that are made in PriceRules, not in code.

Open the API reference

RequestJSONPOST /api/v1/pricing/resolve

{
  "customer_id": "ACME-BUILD",
  "products": [
    {
      "sku": "VLV-304",
      "quantity": 120
    }
  ]
}

ResponseJSON200 OK · sample data

{
  "mode": "business",
  "success": true,
  "data": {
    "customer_id": "ACME-BUILD",
    "items": [
      {
        "sku": "VLV-304",
        "base_price": 48,
        "quantity": 120,
        "final_price": 39.5,
        "applied_rule": {
          "id": "rule_acme_vlv_100",
          "name": "Acme volume price 100+",
          "type": "fixed",
          "value": 39.5,
          "constraints": {
            "minimum_quantity": 100
          }
        },
        "match_reason": "MOST_SPECIFIC_RULE",
        "pricing_summary": {
          "savings": 8.5,
          "message": "Customer saved 8.50 due to active pricing rules"
        }
      }
    ]
  },
  "billing": {
    "limit": 2000,
    "usage": 194,
    "remaining": 1806
  },
  "meta": {
    "request_id": "req_…",
    "processing_ms": "…"
  }
}

Pricing sandbox

Check a price before a customer sees it.

The problem: When a price looks wrong, someone has to work out which spreadsheet, override or code path produced it.
How PriceRules handles it: The in-app pricing sandbox resolves any customer, SKU and quantity with your live rules and shows a calculation trace — the base price, the rule that was applied, and the resulting unit and total price — without using your API quota.

Same resolution logic as the API.
Useful for verifying a new import or rule before your applications rely on it.
Onboarding can load a sample dataset so you can try it before importing your own data.

Why it matters: Pricing questions get answered by looking at the rule, not by debugging an integration.

Getting started guide

How the winning rule was found · sample data

Customer: ACME-BUILD
SKU: VLV-304
Quantity: 120

1This customer + this SKUAcme volume price 100+ → $39.50
2This SKU, any customernot needed
3This customer, any SKUnot needed
4All customers and SKUsnot needed

Usage, limits & access

Know where you stand on volume, capacity and access.

The problem: Usage-based pricing APIs are hard to budget for when you can't see consumption until something stops working.
How PriceRules handles it: The usage page shows monthly price resolutions and workspace capacity against your plan. Workspace owners get an email at 90% and at 100% of the monthly resolution quota.

Each product line resolved counts as one resolution, for single and bulk requests alike.
Per-minute rate limits by plan (20 to 1,000 requests per minute), with Retry-After headers.
Multiple API keys per workspace on paid plans, with an activity log of key, product, customer and rule changes.

Why it matters: Usage is visible before it becomes a problem, and every change to pricing data is traceable.

See limits by plan

Usage · illustrative

Price resolutions this month1,820 / 2,000

Pricing rules74 / 200

Products61 / 100

Meters use the Free plan's real limits; usage figures are an example.

See the engine on your own data.

Start on the Free plan, import a few products, customers and rules, and resolve prices in the sandbox or over the API.

Start free Compare plans

Free planNo credit card

Or read the getting started guide