The Catalog Deleted Your Listings Without Telling You: An API Seller's Discovery

Title

The Catalog Deleted Your Listings Without Telling You: An API Seller's Discovery

Meta Description

An API seller discovered the catalog quietly deleted 57 listing records, and 20 mispriced records also vanished after five weeks. Two snapshot comparisons reveal: the catalog has two failure modes, and TTL inference is wrong. Measuring absence matters more than measuring errors.

Article Content

An API seller examining their product catalog discovered: of 153 listing records, 20 were mispriced and 57 mysteriously disappeared—all without their knowledge. More surprisingly, what made their listings vanish was neither pricing errors nor the 30-day expiration rule. This exposes a neglected failure mode in the API economy: your listings may not be delisted—they may be silently deleted by the catalog.

According to the minia2a blog, the seller's listings on the CDP Bazaar index underwent two full snapshot comparisons. The first (October 3) had 153 records pointing to their endpoint, 20 of which marked the price as $0.01 when the actual price was up to $50—an error left over from an old re-signing practice that has been permanently banned. The second (October 19) had only 98 left, and all mispriced records had disappeared.

On the surface this looks like good news: errors were cleaned up at no cost. But the seller points out that the catalog has two failure modes: retaining prices you no longer charge, or simply ceasing to list you. Previously they had only measured the first.

What the Two Snapshots Actually Revealed

Both datasets came from full catalog crawls, not sampling. The index was fetched page by page, merged, and compared line by line per resource host. No settlement occurred, and neither party performed any write operations.

Metric	October 3	October 19
Total catalog rows	24,419	25,800
Our rows	153	98
Price matches live 402	133	98
Price underestimated	20	0
payTo drift	0	0

Between the two snapshots: 57 records disappeared, 2 were added, 96 were retained. All disappeared records had lastUpdated timestamps between September 3 and September 11—37 to 45 days old at observation. All retained records had timestamps on or after September 19.

The most tempting conclusion is: records expire in 30 to 45 days. But the same data says no.

lastUpdated is the field in the catalog index recording when a record was last updated by the indexer (or data source). In the context of API catalogs, it typically reflects the moment a listing entry was re-crawled or re-signed, not when the listing actually changed. Therefore, the age of lastUpdated (current time minus that timestamp) is often misread as "record存活时间" (record lifetime), but it actually only indicates "when the record was last touched by the indexer." If the indexer uses a lazy update strategy, a record may go untouched long before deletion, meaning there is no fixed relationship between lastUpdated and actual deletion time. This is precisely why the TTL inference in the article fails: records on different hosts may exhibit different lastUpdated age distributions due to different indexer crawl frequencies, which cannot be explained by a single cutoff point.

Why the TTL Inference Is Wrong

The October 19 catalog still listed 88 records from other hosts whose lastUpdated was earlier than September 19—the oldest from May 16, 156 days old, spread across 18 hosts. This rules out the existence of a global TTL.

The seller's own data also cannot confirm a TTL: the oldest retained record was 29.5 days old, and disappeared records were 37 to 45 days old, so for their own host the data is equally consistent with a cutoff between 29.55 and 37.77 days. The two snapshots left this 8.2-day gap.

Two snapshots bound a window, but they don't give you a clock.

This lesson was costly. The early working assumption in the seller's notes was "1 to 1.5 days," which would have required paying to re-settle listings daily: seven days would cost about $17.44, while revenue from the catalog over the same period was only $0.53. The actual retention time was more than an order of magnitude longer than assumed, and the mispriced records ultimately disappeared without spending a cent to refresh them. The assumption erred in the expensive direction.

TTL (Time-To-Live) is a common mechanism in caches and distributed systems: each record is assigned a maximum lifetime, after which it is automatically expired and deleted. In the API catalog scenario, if a global TTL existed, all records should be removed at the same age regardless of their source host. But the data in the article shows records from other hosts still listed after 156 days, while the seller's own records disappeared at 37–45 days, directly negating the existence of a global TTL. More subtly, even without a global TTL, there may be differentiated cleanup strategies per host or per source, such as lazy eviction based on endpoint activity or indexer crawl budget. Therefore, the "disappearance age" observed from two snapshots can only serve as an empirical value for that host during that time period and cannot be extrapolated as a schedulable constant.

Monitoring Outage and Operational Lessons

The monitoring that should have detected the 57 disappearing records was not running at the time. It had been correctly disabled due to a third-party egress policy, and the last automated observation was September 21. The records were discovered to have disappeared on October 19 through a manual scan—16 days of silence on a surface judged to have "no buyers."

The seller considers this a defensible trade-off, but only if it is written down somewhere the next session can read. Because a file still saying "run daily via systemd timer" turns an intentional stop into a silent failure.

payTo is the field in API payment protocols (such as x402) used to specify the receiving address. In catalog indexes, payTo drift means this field is inconsistent with the payment requirement actually returned by the endpoint, which may cause buyers to pay to the wrong address or payment to fail. The article mentions payTo drift was 0 between the two snapshots, indicating the payment channel itself was stable and the problems were concentrated in price fields and record persistence. Distinguishing payTo drift from price drift is important: the former is a payment routing error, the latter is a pricing information error, and their remediation actions differ—the former may require re-signing or updating payment configuration, while the latter may simply require waiting for the indexer to re-crawl. Conflating different failure types obscures the real failure mode.

Three Changes to Measurement Approach

The seller adjusted three ways of asking questions, not the index itself:

• Report the number missing. A parity report that only prints "consistent: 98" looks clean whether the catalog has 98 or 153 records. Now the scan states the number of records belonging to them in each snapshot and flags discrepancies, so disappearances are not mistaken for consistency.
• Do not encode TTL from two observations. The guard description now states: removed at 37 to 45 days among own records, no unconditional cutoff, mechanism undetermined. If future changes make refreshing important, what needs re-measuring is the removal age, not a constant for scheduling.
• Distinguish the two determinations. Price drift and record absence are different failures with different fixes. Stale prices are fixed by the endpoint being paid (or the index rechecking); record absence is fixed by re-listing, which may not be a seller-side action at all.

A Narrower but More Useful Conclusion

On October 19, all 98 records in the catalog accurately reflected what the seller charged, with no payTo or payment channel drift. The 20 records that had underestimated prices by up to 5,000x were no longer among them. The catalog achieved this by deleting them, roughly five weeks after they stopped being refreshed.

The seller did not predict this timescale, and still cannot explain the selection rule. But one thing is certain: record absence is a failure mode worth counting, and the retention window inferred from two snapshots is not a scheduling plan.

For API sellers, this is a reminder: the catalog is not a static display board—it has active cleanup rules. Your listings may disappear without your knowledge, and monitoring silence is more dangerous than wrong prices. Measuring absence, not just measuring errors, may be the most practical takeaway from this incident.

One-line Summary

An API seller discovered the catalog silently deletes records, and monitoring silence is more dangerous than pricing errors.

Paragraph Summary

Through an API seller's comparison of two full catalog snapshots, the article reveals a neglected failure mode of API catalogs: records may be silently deleted rather than delisted. Of 153 records, 20 were mispriced and 57 disappeared after 37-45 days, but 88 records on other hosts had persisted for 156 days, ruling out a global TTL. The seller initially assumed 1-1.5 day expiration, leading to $17.44 spent on refreshes over seven days against only $0.53 in revenue. Monitoring was down for 16 days due to a third-party policy, so the disappearance went undetected. The author suggests shifting from measuring errors to also measuring absence, and not inferring TTL from two observations as a scheduling basis.