# Reorder points and order quantities

> What a reorder point and an order quantity are, where they come from, and why the API works them out when you read them.

Markdown twin of https://panlytics.net/developers/concepts/reorder-points (last updated 2026-10-25). Every page of the Panlytics developer docs is listed at https://panlytics.net/developers/llms.txt, and all of them are in one file at https://panlytics.net/developers/llms-full.txt. The site guide is https://panlytics.net/llms.txt.

## Two figures per product

For every product in a category, Panlytics works out two figures.

- **The reorder point** (the level that triggers a new order). When the stock on hand falls to this level, it is time to order. It is a number of pieces.
- **The order quantity**: how many pieces to order when that happens, rounded to whole packs where the pack size is known.

Next to them, Panlytics gives the **days of stock left**: how long the stock on hand lasts at the pace the product sells. A product whose stock is at or under its reorder point is on the shop's order list.

These are the same figures the app shows on a category's pages, its order list and its sheet. The API reads them from the same place, so a program never sees a different answer from the person.

## Worked out when read, never stored

A reorder point is never saved and then read back. Panlytics works the figures out from the category's latest report, its supplier's delivery days and any levels a person set by hand, at the moment they are asked for.

This matters to a program in two ways:

1. **A change shows on the next read.** When a person keeps a product at a level of their own choosing, or a supplier's delivery days change, the next read returns the new figures. There is no job to wait for and nothing goes stale.
2. **There is no history.** Reading the same category tomorrow gives tomorrow's figures. To keep a record over time, save what you read. [Send reorder points to a spreadsheet or another system](https://panlytics.net/developers/guides/send-reorder-points-elsewhere) shows one way.

## What changes them

| Change | Where it happens |
| --- | --- |
| A new report for the category | Uploaded in the app, or with `POST /v1/shops/{id}/reports` |
| The days a delivery takes | A supplier's settings in the app |
| A level a person keeps a product at | An exception on the product, in the app |
| A product marked never to stop stocking | An exception on the product, in the app |

Every figure is worked out when it is read, so a change made in the app or through the API shows on the next read. `POST /v1/categories/{id}/recompute` only refreshes the stored summary the app's shop page shows. See [Recompute after a change](https://panlytics.net/developers/guides/recompute-after-a-change).

## Reading them

`GET /v1/categories/{id}/reorder-points` answers with one row for each product whose reorder point should change: the reorder point now and newly worked out, the order quantity, the stock on hand and the days of stock left. [Read and export reorder points](https://panlytics.net/developers/guides/read-and-export-reorder-points) walks through it.

> [!NOTE]
> A reorder point of `0` is not missing data. On the slowest products, a shop may choose to sell the last piece before ordering again, and the figure says exactly that.
