Observed supplier availability is not a promise to a customer. The three timestamps never to merge, why stock is not a boolean, and how to word the screen.
Key takeaways
- Observed availability is evidence about a display state, not about physical stock and not about ability to supply.
- Three separate timestamps must be kept apart: when the supplier says the figure is true, when you observed it, and when it was shown to a user.
- Availability is not a boolean. The schema.org vocabulary defines twelve distinct availability states, and the differences between them change what you may tell a customer.
- Alert on a transition, not on a state. An item found "out of stock" on every check stops being news after the first alert.
- Where a supplier has an official feed or interface, ask for it. It breaks less often, and very often the supplier was simply never asked.
An observation of availability on a supplier's site says that at one moment, a particular marker was displayed there. It does not say the item is reserved for you, that it will still be there when you order, or that it will arrive on any date. Any screen that translates that observation into a promise to a customer creates a commitment nobody made.
The gap between an observation and a promise
The chain between "the supplier's site says available" and "the customer receives it" contains at least five points where the link breaks:
- The figure on the supplier's site may be cached and not reflect the warehouse at this moment.
- Physical stock is not available stock: part of it is allocated to other customers' open orders.
- A supplier may display "available" for an item they themselves order from a manufacturer on demand.
- The item can sell between the moment you observed it and the moment you order.
- Minimum order quantity, delivery zone or credit terms can block the order even when stock exists.
The professional term on the other side of that gap is available-to-promise: the quantity a system is willing to commit to a customer after existing allocations are deducted. An external observation never computes it, because it cannot see the supplier's open orders. That is the whole explanation for the title: you alert, and you do not promise.
Three timestamps you must never merge
| Timestamp | Who sets it | What it states | What breaks when it is missing |
|---|---|---|---|
source_as_of | The supplier, if they declare it | The moment the supplier's figure is true for | You attribute a freshness the supplier never claimed |
observed_at | You | When your check actually ran | Nobody can tell whether the value is a minute or two days old |
shown_at | The screen | When a user saw the value | A customer reads an old value and assumes it is current |
changed_at | Your system | When the value last moved as far as you know | Stability and a stuck reader become indistinguishable |
The third row is the one that fails first in practice. A dashboard loaded once in the morning and left open all day keeps displaying "available" long after the state moved, because nobody decided that the display itself expires. The fix is simple: every availability value on screen carries a displayed age, and once that age passes a threshold the value is replaced by a message rather than left standing.
Why is "in stock" not a boolean?
Because the common availability states are not two. The public schema.org vocabulary, in version 30.0 published in March 2026, enumerates twelve ItemAvailability members: BackOrder, Discontinued, InStock, InStoreOnly, LimitedAvailability, MadeToOrder, OnlineOnly, OutOfStock, PreOrder, PreSale, Reserved, SoldOut.
Those distinctions are not academic. Discontinued means there is no point waiting, BackOrder means there is, MadeToOrder means the lead time is only fixed at the point of order, and InStoreOnly means availability exists but not in the channel you order through. Mapping all of them onto yes/no deletes exactly the information that dictates what you tell a customer.
So keep two fields rather than one: raw_status - the text as it appeared at the supplier - and mapped_status - the value you mapped it to. When a mapping turns out to be wrong, the raw field is what lets you correct history instead of guessing at it.
What you may tell a customer, per state
| What was observed | What it probably means | What you may tell a customer | Internal action |
|---|---|---|---|
| Marked available, observed under an hour ago | Ordering is plausible | "Observed available at the supplier today at 09:40" | Start the ordering process |
| Marked available, observed two days ago | Unknown | Do not present as available | Refresh before answering the customer |
| A low quantity displayed | Depleting, shortage possible | Do not quote the quantity | Order early or find an alternative source |
| Out of stock | Not present in the channel you checked | "Not currently available at the supplier we checked" | Check an alternative supplier, add to watch list |
| Pre-order or made to order | A date exists only via the supplier | Do not quote a date | Get a written lead time from the supplier |
| Discontinued | It is not coming back | Say so plainly and offer an alternative | Remove from the catalogue and substitute |
The most important cell is the last one in the "may tell" column: under no circumstances do you quote a delivery date derived from an observation. A date is information that comes from the supplier in writing, and the moment it reaches a customer it becomes a commercial commitment.
Alert on transitions, not on states
Alerting on a state produces an identical daily message and loses attention within a week. Alerting on a transition produces news. Four transitions worth an alert:
- Available to out of stock, on an item that appears in your open orders.
- Out of stock to available, on an item sitting on a wait list.
- Available to discontinued, which needs a substitution decision rather than just a purchase.
- A sharp drop in the displayed quantity past a threshold you set, where the supplier displays a quantity at all.
Two mechanisms prevent flapping. The first is double confirmation: only change state after two consecutive checks agree, so a momentary fault on the supplier's site does not raise an alert. The second is a cool-down: after alerting on an item, do not alert on it again for a fixed window. Without both, one bad day at the supplier produces dozens of false alerts, which is the fastest route to nobody reading the next one.
Just as important is an alarm on a silent source. If a supplier reader read zero items across three consecutive runs, that is a fault - not "no changes". The reasoning and the cost of that kind of break are covered in collecting supplier catalogues and prices.
What should the screen actually say?
Wording is part of the design, not decoration. Three examples that carry the same fact without committing to it:
- Instead of "in stock" - "observed available at the supplier on 14 Aug at 09:40".
- Instead of "delivery in 3 days" - "lead time is provided by the supplier at the point of order".
- Instead of "only 4 left" - "the supplier displayed low stock; the quantity is unverified".
On an internal screen, add an age indicator to every row. On a screen a customer sees, do not display an availability figure sourced from an external observation at all - show only your own stock. The boundary between your stock and someone else's is worked through in syncing stock between a shop and a website, and the purchasing processes that rest on it in automating inventory management.
Ask the supplier before you build
The question almost nobody asks is "do you have a stock file?". Mid-size suppliers and above usually do, and they are generally willing to send it to a regular customer. What to ask for, in order of preference: a documented interface; a daily file in a fixed format; a shared sheet that is kept updated; and finally a written lead-time commitment for your core items.
An official feed solves more than a technical problem. It arrives with a real source_as_of, it does not break when the supplier redesigns, and it turns availability into a figure agreed between two parties instead of an interpretation of a screen.
Sources
Frequently asked questions
Can I show my customer the supplier's stock?
Structurally it is a risk: you display a figure you neither control nor can verify, and in practice you convert it into your own commitment. The safe practice is to display only your own stock and use supplier data internally for purchasing and alerts. The contractual question is separate and is settled with the supplier.
How often should supplier availability be checked?
By the decision window. If a purchase order is written once a day, a daily check is enough. If you sell fast-moving items and commit to customers the same day, a higher frequency is needed - and even then the answer to the customer rests on a point-in-time refresh, not on the stored value.
Which is better, an exact quantity or an availability marker?
The marker is more reliable, because quantities shown on supplier sites tend to be rounded, hidden above a threshold, or reported at warehouse level rather than branch level. A quantity is useful when the supplier provides it in an official feed and states what it means. Otherwise treat it as a signal.
How do you find out the availability mapping is wrong?
Store the raw text alongside the mapped state, and review the unrecognised raw values once a month. New supplier wording - say "temporarily out" against "out of stock" - shows up there before it causes a wrong decision, and it is the cheapest check in the system.
Keep reading
Related service
Business Automation
I build custom automations that remove repetitive work end to end.
About the author
Yehonatan Saadia
Freelance automation, web & MVP developer
I'm Yehonatan Saadia, a senior developer who builds business automation, custom websites, and MVPs for small and mid-sized companies across the US, Europe, and Israel. These guides come from real client work, not theory.
Work with meHave a project like this?
Tell me what you're trying to automate or build. I reply within 24 business hours with a few targeted questions, then we walk through it on a free 30-minute call, with no commitment. You come away with a scope, a timeline and a fixed price - or a straight answer that it isn't worth building.