What needs doing about one supplier
What is wrong with one supplier right now, in four sections.
purchase_orders is a worklist: one item per order needing a look, with po_id, the order's display number, its status, a message_key of cancelled, delayed, shipped, quantity_changed or expected_delivery_date_passed, and email, the supplier's message the signal was read out of, or null where the order is simply past its expected delivery date. total_count counts the items.
An email is the stored message, and its body belongs to the person whose mailbox it arrived in. A key is nobody's colleague, so it reads each mailbox at the level that mailbox shares: on the default level body, html_body, clean_body and quoted_body come back null with body_withheld saying so, and a mailbox shared with Tightly only keeps its messages out of the section, leaving email null. says, files, decision, with_party, tag and waits_on_you are answered by the Mail reads, not by this one.
replenishment_readiness counts this supplier's variants with no lead time and with no unit cost, which are the two figures a reorder cannot be computed without. smart_replenishment counts the variants at critical stock. supplier_configuration says whether a default lead time and a minimum order value are recorded, and how far the configured lead time is from the measured one.
Counts and a worklist, never rates. get_supplier_overview is the door for the figures a scorecard prints.
Scope: suppliers:read.
Request
- Base URL: https://api.app.tightly.io
- URL: https://api.app.tightly.io/api/v1/inventory/suppliers/{supplier_id}/needs-attention
- Auth: HTTP bearer
Path parameters
The supplier's id, as list_suppliers serves it.
Headers
The date train to answer on. One train exists today, 2026-11, the one this reference describes and the one every key is minted on, so the call answers on it with or without this header. Send it anyway, so a client built now names its train from the start.
Response
The four sections. Every count is a whole number and never null; purchase_orders.items is empty when there is nothing to do.
An item's email is the supplier's message the signal was read out of: its subject, its people, its dates, the files that came with it (attachments, each with id, filename and mime_type, and a stored file may carry keys beyond those three, which are ignored rather than refused), and the message itself where this caller may read it. read_at is when Tightly read the thread, or null.
A connected mailbox carries one of three sharing levels, and a key is never the person who connected it, so a key reads every mailbox at the level that mailbox shares. At the default level the four body fields (body, html_body, clean_body, quoted_body) are null and body_withheld carries the sentence saying so; at Full messages they are served as they always were; and a mailbox shared with Tightly only has its messages left out of this section altogether, so the item carries email: null with the order, its status and its message_key unchanged.
says, files, decision, with_party, tag and waits_on_you are part of the shared message shape and are null on this operation. They are read from a thread, and this section reads messages one at a time by id.
Changes
No recorded changes to this operation across all 1 revision of this API.