---
title: "What this account should be sent next, ranked by impact"
method: GET
path: "/api/v1/wholesale/retailers/{partner_id}/replenishment-recommendations"
tags: ["wholesale"]
---

# What this account should be sent next, ranked by impact

`GET /api/v1/wholesale/retailers/{partner_id}/replenishment-recommendations`

## Request

- Base URL: `https://api.app.tightly.io`
- URL: `https://api.app.tightly.io/api/v1/wholesale/retailers/{partner_id}/replenishment-recommendations`
- Auth: HTTP bearer

What this account should be sent next, highest composite score first: one row per variant with the recommended quantity, the impact level, the replenishment date, the destination location and the default supplier, and `production_type` saying which act follows, a basket for a bought item or a manufacturing order for a made one.

`their_rule` is the account's own reorder rule for that variant, as its file stated it: `min_stock` and `max_stock` in units, the `sell_from` / `sell_until` window and the `as_of` date of the file. It is theirs, not a recommendation, and is null where the account has stated none; a field they left unstated is null.

`partner_id` is the account and `limit` bounds the rows.

A recommendation is advice, not an order. Placing it is create_purchase_order or convert_basket_to_purchase_orders; nothing here reserves stock or contacts anyone.

Sold with Essentials+: without Tightly Connect the answer is 403 `plan_excludes`.

Scope: `accounts:read`.

## Path parameters

- `partner_id` string, required

## Query parameters

- `limit` integer

## Headers

- `Tightly-Version` string

## Response `200`

`rows`, ranked by composite score, each with the quantity, the date and where it ships from.

- object
  - `data` object
    - `rows` object[]
  - `message` object: severity, service and desc.

## Other responses

- `400`: `limit` is not an integer.
- `401`: No usable key: malformed, unknown, revoked, expired or stopped. One refusal covers all five, telling a caller which is which maps the surface for them. A request with no Authorization header at all is refused 400 before any key is looked for.
- `403`: The key may not reach this operation. `plan_excludes` when Accounts is sold with Essentials+ and this organisation's plan does not include it; `scope_missing` when the key does not hold Accounts; `organization_mismatch` when the path names an organisation that is not the key's; `ip_not_allowed` when the caller's address is outside the key's allowlist; `account_mismatch` when a key issued to one account names another in the path, and the sentence names both accounts.
- `429`: The key has spent its allowance for this minute. 600 reads and 120 writes a minute, counted per key, refused calls included. `Retry-After` says how long to wait.
- `503`: The database is briefly out of reach, which is what a failover or a full connection pool looks like from outside. Wait the seconds `Retry-After` names and send the request again. A read is safe to repeat. A write is not, because the connection was lost in the middle of it, so read the object back before sending it a second time. Branch on the status rather than on `code`, which is `POSTGRES_UNAVAILABLE` from one of the two seams that raise this and `SERVICE_UNAVAILABLE` from the other.

---

[API](https://skmtc.dev/tightly/apis/tightly-api.md) · [All operations](https://skmtc.dev/tightly/apis/tightly-api/llms.txt) · [OpenAPI document](https://skmtc.dev/tightly/apis/tightly-api/revisions/199f7eb35afb?raw)