Public API support for stock items and supplier purchasing details

Ideas & feature requests
1

We would like to request public API support for managing stock items and their supplier-specific purchasing details.

Our brewery uses multiple ingredient suppliers, each with customer-specific pricing, SKUs and package sizes. A single Breww stock item may be available from several suppliers, and each supplier may offer multiple purchasing variants.

For example, one Citra stock item could have:

  • Supplier A: 100 g, 500 g and 1 kg packages
  • Supplier B: 1 kg and 5 kg packages
  • Different SKUs, prices and minimum order quantities for every variant

The Breww UI already represents this structure well. We would like the public API to expose the same data model.

Requested capabilities:

  1. Read, create and update stock items.
  2. Read, create and update supplier item details attached to a stock item.
  3. Support multiple suppliers and multiple package sizes per stock item.
  4. Expose stable identifiers for each supplier purchasing variant.
  5. Support these fields:
    • Supplier
    • Supplier SKU
    • Supplier quantity / package size
    • Minimum order quantity
    • Expected net price
    • Currency
    • VAT treatment or rate
  6. Allow stock item names and units of measure to be updated.
  7. Ideally expose updated timestamps or webhooks for change reconciliation.

Our use case is an external Supplier Intelligence service that:

  • Reads authenticated, customer-specific B2B catalogues.
  • Detects price, SKU, package-size and availability changes.
  • Maps supplier variants to the stock items used by recipes in Breww.
  • Keeps expected purchasing prices current.
  • Preserves a full audit trail and requires explicit approval before writing anything.

We do not need to alter historical receipts, landed costs, batches or recipe consumption. The integration would only maintain catalogue and expected purchasing information.

A scoped write permission would be ideal, but using a separate full-access API key would also be workable if the endpoints followed the existing Breww API conventions.

If API support is not currently feasible, a structured CSV import/update format for stock items with multiple supplier purchasing variants would be a valuable intermediate solution.

2 Likes