Changelog

v1.6.1 (Current)

Released: August 2026

MCP tools

Permission-aware tool calls: MCP tool calls now respect user permission profiles. A call that touches data the calling user’s permission profile does not allow now returns a code="permission" error with the message “Permission denied: your permission profile does not allow this action. Ask a workspace admin to update it.” instead of the previous behaviour. Rolling out gradually per workspace.

v1.6.0

Released: August 2026

MCP tools

The MCP surface versions independently of the REST endpoints below; this change is listed here because it is customer-visible.

Stricter tool input validation. Every MCP tool’s input schema now declares "additionalProperties": false at the top level, so calls that include unknown top-level fields are rejected instead of having those fields silently ignored. No parameter was added, removed or renamed. Clients that send only the documented parameters are unaffected.

New Features

Retail price on SKUs: POST /api/v1/skus now returns retail_price, the current Shopify selling price in your store’s default currency. It is the same value already returned as retail_price on purchase-order lines, so a SKU export and an order export now agree without a join. A number at SKU and SKU_LOCATION, and a {min, max} object at PRODUCT covering the product’s SKUs — the same shape days_on_hand uses there.

Notes

The field is omitted for a SKU Prediko holds no price for in your store’s default currency — raw materials, typically. Purchase-order lines differ here: they report 0 in that case rather than dropping the field.
retail_price is the live catalogue price, not the price captured on any past date. That is true of the purchase-order line field too: a line’s retail_price reflects today’s selling price for that SKU, not the price when the order was placed. Prediko does not currently expose historical price-at-date.
The field is additive — no existing field changed name, type or meaning. Clients that ignore unknown fields are unaffected.

v1.5.0

Released: August 2026

New Endpoints

GET /api/v1/bundles - List bundles and the SKUs each one is composed of

New Features

Bundles: Pull the bundles (kits) configured for your account, each with the list of child SKU names it’s made up of. Useful for reconciling sales/forecast data at the component level when a customer buys a bundle.
ABC category on SKUs: POST /api/v1/skus now returns abc_category, the ABC classification Prediko computes for each SKU from your ABC settings. Available at every aggregation_level — a string at SKU and SKU_LOCATION (null when the SKU is unclassified or ABC is not configured), and an array of the distinct categories across a product’s SKUs at PRODUCT. Category names come from your ABC settings, so treat the value as a string rather than a fixed A/B/C enum.
Per-line cost on purchase orders: POST /api/v1/orders lines now accept an optional unit_cost, expressed in the supplier’s currency. Previously a cost sent in the payload was silently dropped, so there was no way to set a PO line’s cost through this endpoint.

MCP tools

The MCP surface versions independently of the REST endpoints above; these changes are listed here because they are customer-visible.

Reorder status is now writable. update_sku_settings takes re_order_status (boolean) in a SKU patch — the app’s Reorder Yes/No column. It was already readable as a metric and filter on search_inventory. status (active / discontinued) is the deprecated spelling of the same field and still works; passing both in one patch is rejected.
Reorder status at product granularity. search_inventory with granularity: "product" now returns re_order_status as a {yes, no} count of the product’s SKUs instead of rejecting the metric. It stays a boolean at sku and sku_warehouse granularity.
Setting re_order_status: true on a bundle SKU is now rejected. Prediko always excludes bundles from re-order planning, so the call previously succeeded and changed nothing. Set it on the bundle’s component SKUs instead.

Fixed

update_sku_settings silently skipped bundle and archived SKUs: they resolved as valid but then matched nothing on the write, so a batch containing them reported every SKU as updated while only the others changed.
Cost fields sent on POST /api/v1/orders lines (cost, unit_cost, unit_cost_supplier) were accepted with a 200 and then discarded, never reaching the purchase order. Send unit_cost to set a line’s cost; the other two names are still ignored.

Notes

abc_category and unit_cost are both additive — no existing field changed name, type or meaning. Clients that ignore unknown fields are unaffected.
Cost resolution on PO lines is unchanged when unit_cost is omitted: Prediko still resolves the SKU’s supplier-specific cost for that line’s supplier, falling back to the SKU’s generic unit cost. Only send unit_cost to override what Prediko already holds. A negative unit_cost is rejected with 422; 0 is kept as a real cost (free samples) rather than treated as unset.

v1.4.0

Released: July 2026

Changed

POST /api/v1/transactions now takes store_name instead of store_id. Store names are what you see in Prediko, so no internal identifier is needed. Matching ignores case and surrounding whitespace — URL-encode names containing spaces.

Deprecated

store_id on POST /api/v1/transactions. It is still accepted so existing integrations keep working, but it will be removed in a future version. Supply either store_name or store_id, not both — sending both returns 422.

Fixed

An unrecognised store is now rejected with 422, listing the store names available on your account. Previously an incorrect store_id returned 200 and the transactions were recorded against a store that did not exist, so they never appeared in Prediko.
Transaction dates: timestamp values on the 1st-12th of a month were being recorded in the wrong month — the day and month were transposed, so 2026-12-03 (3 December) was stored as 12 March. Dates from the 13th onward were unaffected. ISO 8601 timestamps are now recorded exactly as sent.
A timestamp that is not a valid ISO 8601 datetime is now rejected with 422 rather than being interpreted as a best guess.

Notes

This is a behaviour change for anyone currently sending an invalid store_id: those requests returned 200 before and now return 422. The data was not being recorded in either case.

v1.3.0

Released: July 2026

New Endpoints

PATCH /api/v1/skus - Update attributes on up to 200 SKUs per call

New Features

SKU updates: Set a SKU’s reorder status (patch.re_order_status) — true (Yes) makes it replenishable and included in reorder recommendations, false (No) excludes it from replenishment. This is the writable counterpart of the re_order_status field already returned by POST /api/v1/skus.
Extensible patch body: the endpoint takes a patch object rather than a per-attribute URL, so further SKU attributes (lead time, MOQ, minimum/maximum days on hand) will be added as additional patch fields without a new endpoint or a breaking change.

Notes

Bundle SKUs cannot be given a reorder status of true — they are replenished through their components — and return 422.
Setting re_order_status to false also dismisses stock-health alerts for those SKUs; re-enabling does not restore previously dismissed alerts.
POST /api/v1/skus serves from a planning dashboard rebuilt by a queued refresh, so it can report the previous value for several minutes after a write. Treat the 200 from PATCH /api/v1/skus as the confirmation.

v1.2.0

Released: March 2026

New Endpoints

GET /api/v1/orders/delivery - List deliveries (stock arrivals) across all orders with optional date filtering
GET /api/v1/bill-of-materials - List BOM recipes for all finished goods (JSON or Excel format)
GET /api/v1/orders/{id}/consumption - Get raw material consumption per production order
PUT /api/v1/orders/{id}/consumption - Update actual consumption quantities for yield/waste tracking

New Features

Bill of Materials: Pull BOM recipes showing which raw materials compose each finished good and in what quantities. Supports JSON (paginated) and Excel export formats
Production Consumption: Query raw material quantities planned and consumed per production order, with automatic variance calculation for yield/waste tracking
Variance Tracking: Computed quantity_variance field on consumption data (positive = loss, negative = better yield)
Deliveries: Each line now exposes order_id, created_at, and a stable 10-character shipment_id (hash of order_id + the created_at calendar day). Lines from the same order recorded on the same created_at day share the same shipment_id. The created_after / created_before filters now accept ISO 8601 datetimes and apply on the new created_at field.

New Fields

SKUs: Added period sales metrics as default response fields across all aggregation levels (SKU, SKU_LOCATION, PRODUCT). For each weekly / monthly / quarterly / yearly window: *_quantity (units sold, historical), *_plan_quantity (forecast unit sales plan), *_sales (sales revenue, historical), and *_plan_sales (forecast sales revenue plan) — 16 columns in total. This lets API consumers pull historical units sold and the sales plan (e.g. past/next 3 months) programmatically.

v1.1.0

Released: March 2026

New Fields

SKUs: Added RE_ORDER_STATUS (re-order status), supplier_name, RECOMMENDED_UNITS_TO_ORDER, and lead_time_to as default response fields across all aggregation levels

New Features

SKUs: Added PRODUCT aggregation level to retrieve inventory data aggregated by product

v1.0.0

Released: January 2025

Initial release of the Prediko Public API.

Endpoints

GET /api/v1/orders - List orders
GET /api/v1/orders/{id} - Get order details
POST /api/v1/orders - Create or update orders
PATCH /api/v1/orders/status - Update order status
DELETE /api/v1/orders/{id} - Delete order
POST /api/v1/skus - List SKUs (paginated)
GET /api/v1/suppliers - List suppliers
GET /api/v1/warehouses - List warehouses

Features

Orders: order_types filter includes FINISHED_GOOD, RAW_MATERIAL, and PRODUCTION_ORDER options
Orders: aggregation_level parameter supports SKU (aggregated) and SKU_LOCATION (by warehouse)
SKUs: aggregation_level parameter supports SKU (aggregated, default) and SKU_LOCATION (by warehouse)
Pagination: Only the SKUs endpoint is paginated (max 5000 results per page)