Designing RSS and API Feeds So Price Drops Reach Readers in Minutes

This is the third post in our series on building Savlume (https://savlume.com/), a US deal tracker. The first covered our deal verifier and the MCP + llms.txt layer (https://savlume.com/llms.txt); the second covered automated price tracking and GEO/AEO (https://savlume.hashnode.dev/building-an-ai-shopping-assistant-automated-price-tracking-and-geo-aeo-in-practice). This one is about the plumbing in between: the RSS and API feeds that carry a price drop from our catalog to a reader, a feed reader, or another agent — fast, without duplicates, and without lying about what changed.

1. Why feeds, not just pages

A deal page is a snapshot. A feed is a changelog. When a price drops, the useful event is not "this page exists" but "this item's price changed at this time, from this to that, with this evidence level." Readers who follow deals need the event; agents who answer shopping questions need it too.

Savlume ships three feed surfaces for the same catalog:

• /feed/all.xml (https://savlume.com/feed/all.xml) — RSS for all updates, the one feed readers and automation tools already know how to consume.
• /api/v1/items (https://savlume.com/api/v1/items?mode=all&limit=24) — paginated JSON for every item, plus /api/v1/items/{id} for a single item.
• /api/mcp (https://savlume.com/api/mcp) — an MCP endpoint so an AI agent can query the catalog directly instead of scraping pages.

One catalog, three doors. The rule that keeps them honest: every surface reports the same price, the same verification status (retailer-verified or source-reported), and the same timestamps. A feed entry that disagrees with the page it links to is worse than no feed at all.

2. What goes into a feed entry

Each entry carries the minimum a reader needs to decide in seconds, and nothing they have to re-verify by clicking:

• The item and its canonical URL — the Savlume item page, so the entry is citable.
• The current price and the reference price, as separate fields — so a "40% off" claim can be checked, not just believed.
• The verification status — retailer-verified (confirmed at the retailer's own listing) or source-reported (from a deal source, not yet confirmed at the retailer). The status travels with the price; it is never stripped in the feed.
• Publication, update, and verification times — when the item was listed, when the entry last changed, and when the price was last checked. A price without a time is a rumor, and a feed that hides the check time turns rumors into headlines.
• The conditions — coupon required, Prime required, limit per customer, free shipping or not. A price that only exists with a coupon is not the same price.

What we deliberately leave out: cashback, gift cards, and points are never subtracted from the checkout price, and expired or out-of-stock entries are kept as reference, never as recommendations. A feed that promotes a dead deal is a feed readers unsubscribe from.

3. Deduplication: the same drop, once

The hardest feed problem is not speed — it is not repeating yourself. A price that flickers between two values, or a page that gets re-saved without a real change, must not produce five entries for one event. Our rules:

• An entry is emitted only when the price, the verification status, or the availability actually changes. A re-save with no change is not an event.
• The same product, variant, and conditions are one item. Historical comparisons only compare identical conditions; a different coupon or a different variant is a different record, not an update to the old one.
• Missing information stays unknown. If a check fails, we report "couldn't verify," not "deal dead" — and a failed check does not emit a new entry pretending the price moved.

The practical effect for a subscriber: the feed is quiet most of the day and noisy exactly when something real happens. That is the trust contract of a feed — every entry should be worth the interruption.

4. Polling, caching, and not hammering the retailer

A feed does not remove the need to check prices; it changes who checks what, and how often. Our catalog checks run on our side, and the feed is the public result of those checks. Consumers poll the feed on a sane interval instead of scraping retailer pages themselves, which is better for everyone: fewer requests to retailers, and one verified answer instead of a hundred unverified guesses.

Two design choices that matter:

• Stable item IDs and canonical URLs. A feed reader can tell that today's entry is the same item as yesterday's, so it can show "price dropped from $X to $Y" instead of "a new product appeared."
• Machine-readable text per item. Every item also has a /items/{id}/markdown text version, so an agent or a feed consumer that wants the clean facts can quote them without parsing HTML.

5. What we would do differently next

If we rebuilt the feed layer tomorrow, we would add per-category feeds (one RSS feed per guide category, so a reader who only cares about kitchen deals does not get headphone drops), and a "verification changed" event type distinct from "price changed" — because a price that goes from source-reported to retailer-verified is news even when the number stays the same.

For now, the single all-updates feed does the job: one place where every real change appears once, with its evidence attached.

Try it

• Browse the deals: Savlume (https://savlume.com/)
• Subscribe to all updates: https://savlume.com/feed/all.xml
• Read the machine-readable index: https://savlume.com/llms.txt
• API guide for agents: https://savlume.com/agent
• Example buying guide: Top 5 Air Fryers Under $100 for Black Friday 2026 (https://savlume.com/best/air-fryers-under-100)

Follow Savlume Deals on WhatsApp: https://whatsapp.com/channel/0029VbE9P7J7DAX7rD8TAC2U