Check vendor pricing stability and risk

Which name you asked about and which record answered. A name we hold verbatim matches exact. A name we do not hold matches inferred only when a vendor name we do hold appears in it as a whole word or dotted segment — "AWS Lambda Free" resolves to AWS, "launchdarkly.com" to LaunchDarkly. A fragment that merely appears inside a longer vendor name resolves to nothing and returns 404 with suggestions, because an accidental hit used to be returned shaped exactly like an exact one (#1269).

Non-null only where a check reached a conclusion about the destination: a 404 confirmed by a full request, a 410, or a hostname with no address. Being refused (403, 429, 5xx, timeout) is evidence about our checker and never produces one of these.

The single dated record that produced a non-stable risk_level. Never null when risk_level is caution or risky (#1038) — a client that renders the level must be able to render the reason.

Non-null where every record that would have set a non-stable risk_level either carries an empty source_url (no_source, #1352) or is a change our automatic re-read recorded that neither an archived copy of the vendor's page nor our own check has confirmed (unconfirmed, #1952). The level is withheld rather than reported as stable, and the records are named on the vendor page as unsourced or unconfirmed. Where both kinds are withheld, reason is that of the record that would set the most severe level, and unconfirmed on a tie; records counts both.

Why we do not rank this offer, or null where we do. The same verdict rankOffers applies, from the same function (#1241) — nothing is filtered out of a response because of it, so a caller asking whether an offer exists still gets the record. The full code table is published at /criteria.

What we found on the page at url when we last read it, and so how much of this record that page supports. The outcome grades our evidence, not the offer (#1268).

How this response ordered the entries it names, and how many there are. The order is a permutation seeded only on the UTC date and the query key, so anyone can recompute it. tie_count is how many entries carry no recorded demerit and so are indistinguishable under every signal we hold; ranked_total is how many entries the seed ordered in all. A door that names alternatives names ranked_total of them, never a prefix (#1774). /api/details/{vendor} and /api/vendor-risk/{vendor} both return this block at the top level of the response and name the same alternatives as each other, but they rank under different query keys — related:<category>:<vendor> and vendor-risk-alternatives:<vendor> — so for most vendors the two orders differ. query_key says which ranking produced the order you are reading.

Every alternative we hold in this vendor's category, in the order tie_break describes. Not a selection of them (#1774).

Where the figures in this response came from and how to attribute them. Every response carrying index data has one, under the key _provenance. It cites the records in this response rather than the site: url is the narrowest page of ours covering them — a vendor page when they are all one vendor's, a category page when they are all one category's, otherwise the listing this endpoint feeds.