A variant's recent stock movements
/api/products/{id}/variants/{variantId}/stockSame shape GET /api/products/{id}/stock takes, off the separate book_product_variant_stock_movements ledger (migration 20260918100000): a variant's stock history is independent of its parent product's (frozen, unused) own stock_on_hand. Appointments only, see POST /api/products.
Authorization
sessionCookie The dashboard's Supabase Auth session cookie, set at sign-in. Large sessions are split across
numbered chunks (…auth-token.0, .1), so treat this as a cookie family rather than one name.
Every request re-validates it against the Auth server (getUser()), never by decoding the cookie
locally: a JWT nothing has checked is not a credential. Tenancy is then read from the verified
app_metadata.company_id claim and enforced by row-level security; it is never read from request
input, on any route, ever.
role (admin / staff) is deliberately not in RLS. It gates specific actions in route code,
the operations marked admin below, so hiding a button in the UI is cosmetic only, and a route's
own check is the enforcement.
In: cookie
Path Parameters
Product id (routing only, not consulted by the RPC).
book_product_variants id.
Response Body
application/json
application/json
application/json
application/json
curl -X GET "https://example.com/api/products/string/variants/string/stock"{ "movements": [ { "id": "497f6eca-6276-4993-bfeb-53cbbbba6f08", "reason": "received", "delta": 0, "resulting_stock": 0, "note": "string", "created_at": "2019-08-24T14:15:22Z" } ]}Adjust a product's stock POST
Three reasons, two shapes. `received` and `damaged` send a signed `delta` (the route itself flips the sign for `damaged` client-side, BeNotely's own "how many you're removing" framing, never a typed minus). `stocktake` sends the counted `count` instead; book_product_stock_adjust() (migration 0176) computes the delta against the LIVE, row-locked current value, never a value the client read moments earlier. Every call writes a reasoned book_product_stock_movements row. **Appointments only**, see POST /api/products.
Adjust a variant's stock POST
Same three reasons and two shapes POST /api/products/{id}/stock takes, calling book_product_variant_stock_adjust() (migration 20260918100000) against the variant's own stock_on_hand instead of the parent product's. **Appointments only**, see POST /api/products.