DEV Community: Delta Tools

How to Check a Business Name for Trademark Problems Before You Build the Brand

Delta Tools — Fri, 23 Oct 2026 16:36:26 +0000

How to Check a Business Name for Trademark Problems Before You Build the Brand

TL;DR: Check a business name against live USPTO trademark records before you pay for a logo, a domain, packaging, or launch copy. Start with the exact name. Then search the distinctive word on its own, the distinctive word with the product word, and spelling or sound variants a customer might use. Read live records first, and judge them by class together with related goods and services. An exact search can return nothing while a close live mark is sitting in the same trade space. A screening pass helps because it scores near matches, groups them by class, names the owner and status, and gives a plain reason for each match. Treat the results as research. A legal clearance decision needs more than a screening pass.

You have the name on a sticky note. It is on your phone. It is in the group chat. Someone has already said it out loud in the voice you would use in an ad, and everyone nodded like the hard part was over. The domain looks available. The social handle looks available. A designer can start Monday. The label printer can start as soon as the logo lands. This is the exact moment to slow down for one unglamorous job: check whether the name is already doing work for someone else in the trademark register.

I have watched this scene from the wrong side too many times. A founder falls in love with the sound of a name before asking whether the name can safely carry money. The love is understandable. Naming is the first piece of the business that feels real. It is also the cheapest piece to change before the brand is printed, posted, packaged, and promised to customers.

Think of a business name check as a practical pause. You are looking for live trademark records that are identical or close enough to raise a real question, especially when the goods or services are the same or related. A field full of similar live marks can mean confusion risk, weak distinctiveness, or both. A quiet field proves little on its own. It means the federal register did not show you an obvious problem in that pass.

The short answer before you spend money

Run four searches for every serious finalist. Search the exact name. Search the word that carries the brand. Search that word with the product or service word. Search the versions people might type after hearing the name once. For each live record that looks close, write down the mark, the owner, the status, the Nice class, the goods or services, and the reason it caught your eye.

Then make a calmer decision. If the closest live marks share your distinctive word and sell the same or related things, pause and get advice before you build. If the close marks are in unrelated fields, the name may still be usable, but you now know why you think so. If the search shows only descriptive overlap, note that too. If the field looks crowded in several directions, ask whether the name deserves the fight or is simply the first name the team learned to love. Keep the notes either way, and rename while renaming is still an afternoon. The lasting value sits in the reasons you gather before emotion spends the budget.

Why available everywhere else can still mislead you

A domain registrar answers a narrow question: is this exact web address unclaimed right now. A social platform answers a similar narrow question about a handle. Neither one searches trademark rights. A name can be free as a domain and still be taken as a mark for the thing you plan to sell. These systems do not check with each other.

The trademark question is about source confusion in the market. If customers see two similar names on the same or related goods or services, would they wonder whether the products come from the same company or from connected companies. That is why a name check cannot stop at identical text. Spelling can change while the sound stays close. A descriptive word can be swapped while the distinctive word remains the part customers remember.

Class matters because trademark records are organized by the goods and services claimed. The Nice class is a sorting system for those claims. It helps you find the neighborhood where a mark lives. It does not build a wall around that neighborhood. Coffee sold as a product and coffee served in a café sit in different classes, yet a customer can meet both in the same morning from brands that feel connected. Related goods and services are the risk because customers do not experience your legal categories. They experience shelves, menus, search results, apps, and recommendations.

The manual USPTO check

The manual method works. It takes patience, and it teaches you the shape of the register before any tool scores anything for you. Use the USPTO Trademark Search system and work through the same steps for each finalist. You will find it at tmsearch.uspto.gov, and the basic search by mark text is the right place to begin. A search you cannot reconstruct later is only a mood.

Write the name the way customers will see it and say it. Put the exact spacing and capitalization aside for a moment, because customers will not preserve your styling when they search, speak, or recommend you. Say the name out loud. If it sounds like another word when spoken quickly, write that version down too.
Split the name into the part that carries memory and the part that describes the offer. In Nimbus Coffee Roasters, Nimbus is the part a customer is most likely to carry away. Coffee and Roasters describe the business. Descriptive words still matter, especially in crowded categories, but the memory word usually decides whether two names feel close.
Search the exact name first. Look for live records before dead ones. For each serious record, note the mark text, owner, status, Nice class, and the goods or services language. A live exact match in your field deserves your full attention, because the search just did its job early.
Search the memory word on its own. A founder searching only the full name may miss a shorter mark that contains the important word and covers the same customers. The shorter mark can be the one people remember, cite, and confuse with yours.
Search the memory word with the product or service word. Try the pairing customers would use if they described your business in plain language. For a coffee name, that means the brand word with coffee, café, roaster, or the service you actually plan to offer. Build your own final list from the words your customers actually use.
Search variants that come from ears and keyboards. Change a letter. Drop a vowel. Swap the order of words. Write the plural and the singular. Write the version a person might type after hearing the name in a noisy room. Trademark risk often lives in the gap between what looks different on a screen and what sounds close in real life.
Compare by class and by relatedness. Put the same class records at the top of your notes. Then look hard at related classes before you relax. Ask where the customer meets the goods or services and whether one brand could plausibly extend into the other space. A café service and packaged coffee are not the same claim, but they are close enough in a customer mind to deserve respect.
Record the reason for every match you keep. A useful note says more than the name of the mark. It says whether the match is exact, whether it shares the memory word, whether it sounds close, whether the goods are related, and whether the record is live.
Repeat the same pass for the final spelling you would actually file or print. Founders often check a working name and then adopt a cousin of it at the last minute. That cousin needs its own search. The register does not care that the change felt small in a design review.

This method is honest work, and for one name it may be enough to reveal an obvious problem. Its weakness appears when the shortlist grows and the dangerous match is not exact. You can spend a long afternoon opening records and copying fields, and still miss the mark that matters because the record is shorter, spelled a little differently, or built from the same memorable word.

How to judge what the manual search finds

Live records come first. A dead record can explain history or show that a field has been busy, but a live record is the one that can stand in your path now. Within live records, start with marks that share the distinctive part of your name. Many coffee brands can use the word coffee. Far fewer should use the same unusual brand word for the same kind of offer.

Next, read the goods and services as a customer would. Strip the record down to what is sold, where it is sold, and who buys it. If those answers sit close to yours, treat the match as serious even when the classes differ. If the goods are truly unrelated, write that down as the reason the match worries you less. Do not let a class number do the thinking for you.

Then look at the whole field. A crowd of live marks built on the same word can be a different kind of warning. It may mean the word is already doing source work for several owners, which can make your name harder to protect and easier to confuse. It may also mean the word is common in the trade. Either way, a crowded result should slow the celebration.

Finally, remember what this search cannot see. The register is federal and public, so local use, state registers, and later filings sit outside it. A careful manual pass lowers surprise. It does not erase it.

What a screening pass adds

Instead of relying only on the exact text you typed, a screening pass compares a candidate name with live USPTO records and scores similarity. The comparison can reward exact text, shared distinctive words, one name containing the other, small spelling changes, and words that sound alike. It can also give common descriptive words less weight than rare words that customers actually remember.

A good screening result puts the closest live matches at the top, groups them by Nice class, and attaches the owner, the status, the similarity score, and the reason each match counted. You still have to read and judge. The difference is that your judgment starts from a ranked field instead of a scattered pile of records.

Delta Tools built the Trademark Clearance Checker for this step. It screens a name against live USPTO records and returns one summary per name with exact and close matches, classes with live matches, a signal level, and the strongest matches with plain reasons. You can run it here: Trademark Clearance Checker. The manual method above is the skill. The checker is the faster pass when a shortlist needs the same treatment applied evenly.

A worked example with Nimbus Coffee Roasters

Nimbus Coffee Roasters is a useful example because an exact search gives the kind of answer that can make a founder relax too early. In the screening run used for this article, the name returned a MODERATE signal. It had 0 live exact matches. It had 60 live near matches at similarity of 0.55 or higher, plus 56 dead records. Live matches appeared in Nice classes 016, 021, 025, 030, 032, 035, 040, and 043.

Zero exact matches sounds clean until you read the top of the near match list. The strongest live match was NIMBUS COFFEE in class 043, owned by Nimbus Coffee LLC, with a similarity score of 0.863. The reasons matter as much as the number. The candidate contains the full text of that mark, shares NIMBUS and COFFEE, and sounds alike. Class 043 is the café service neighborhood, which is close to the heart of a coffee brand even when the candidate also plans to sell beans.

The next match makes the class point even clearer. COFFEE ROASTERS appeared as a live mark in class 030 with a similarity score of 0.86 and owner Coffee Roasters, Inc. Another live match, NIRVANA COFFEE ROASTERS in class 030, scored 0.783. Some of the 60 near matches will be noise once a human reads them. That is normal. A screening list is not a verdict list. It is a reading list, ordered so the records most likely to matter get read first.

MODERATE is the right emotional register for this result. MODERATE settles nothing by itself. It says the field is crowded enough that a founder should pause before ordering packaging. The exact search alone could have produced a calm little celebration. The screening pass shows why that celebration would have been premature.

What screening a shortlist costs

A run starts at 0.001 USD. Each completed screening costs 0.01 USD. A screening that fails does not add the per screening charge for that name.

If ten names complete in one run, the math is 0.001 USD for the run start plus ten times 0.01 USD, which comes to 0.101 USD in event charges. If five finalists complete in one run, the math is 0.001 USD plus 0.05 USD, which comes to 0.051 USD. The numbers matter less than the timing. Names are cheap to question before they are printed and expensive to defend after everyone has fallen for them.

Use that low cost in the right place. Screen the shortlist before design work starts, screen spelling variants before the domain purchase becomes a victory lap, and screen the final name again if the team changes a word or leans into a sound that was not in the earlier favorite.

Honest limits

This part matters, so I will say it without decoration.

A screening reads public USPTO records only. It does not see common law use, state registers, or applications filed after the run finishes.
Similarity scores and the signal level are sorting help for research. They are built from counts and comparisons, not legal conclusions.
A name with no matches is not cleared. A crowded name is not automatically unusable. The register can inform a decision, but it cannot make the legal decision for you.
Only a qualified trademark attorney can give a clearance opinion. If the name matters, if the spend is real, or if a close live mark sits in your field, that conversation belongs in the process.
This article and the checker are screening and research aids. They are not legal advice and not a substitute for a professional trademark clearance search.

Those limits define the case for checking. A first pass exists to catch the obvious and the nearly obvious before money hardens around a name.

FAQ

Is an exact USPTO search enough?
No. Exact search is the right first step and the wrong last step. It can miss shorter marks, spelling variants, sound variants, and names built on the same distinctive word. The Nimbus example had 0 live exact matches and still returned 60 live near matches, including a live NIMBUS COFFEE mark at 0.863 similarity.

What does a MODERATE signal mean?
It means the live record field looks crowded enough to deserve a careful read. In the checker, the signal level is research sorting based on record counts and match strength. MODERATE should slow you down and send you back to the records.

If there are no live exact matches, can I use the name?
Not on that evidence alone. You still need to weigh near matches, related goods and services, common law use, state registers, and the distinctiveness of the name. A clean exact result is a good start. It is not a clearance.

Why does class matter if the names are not identical?
Because customers meet brands in related places. A mark for café services and a mark for packaged coffee can feel connected even though they sit in different Nice classes. Class helps you organize the search. Relatedness helps you judge the risk.

How many names should I screen?
Screen the real shortlist, not just the favorite. Five to ten finalists is a practical range for many early brands, and variants belong in the pass when a spelling or sound change is on the table. At 0.01 USD per completed screening plus 0.001 USD to start a run, ten completed screenings come to 0.101 USD, so the cost of checking the whole shortlist is rarely the hard part.

When should I talk with a trademark attorney?
Talk with one before you file, before a major spend, or when a close live mark shares your distinctive word in the same or a related class. An attorney can judge facts a screening cannot, including use in commerce and the strength of the mark. Screening helps you arrive with better questions and cleaner notes.

Check the name while changing it is still cheap

The goal is not fear. The goal is timing. A name problem found at the sticky note stage is a story you tell later with relief. The same problem found after the brand is built becomes a bill, a scramble, and a new name chosen under pressure. Check first, while the name is still young enough to change. If you want the near matches ranked before you read them, run the shortlist through the Trademark Clearance Checker and start from the top of the list.

Price-Drop Alerts: Monitoring Any Product Page for Changes

Delta Tools — Wed, 21 Oct 2026 15:34:07 +0000

TL;DR: You do not need to keep a product page open in a tab and refresh it like it owes you money. There are three ways to get told the moment a price falls. First, use the trackers and saved searches that already exist for big marketplaces. Second, poll any product page with a short Python script that reads the price the store itself embeds in the page, remembers it, and speaks up only when the number goes down. Third, run a scheduled monitor that does the remembering for you. Delta Tools built one for marketplace listings. It is called the OfferUp Fresh Listing + Price Change Monitor, and it watches OfferUp searches and reports each price drop with the old price and the size of the drop included. All three methods are below, with working code for the second one.

I learned this lesson on a camera lens. The listing sat at $850 for weeks. On a Tuesday morning it fell to $640. By Friday it was back at $810, and it stayed there for another month. I saw none of it, because I checked the page on Monday and again on the weekend, and in my head the price simply was $850. The drop was real. My timing was the problem.

That pattern repeats everywhere once you start looking. Sellers cut prices quietly. Stores run short sales that never get announced. A marketplace seller who has had no messages in ten days trims $40 off a listing rather than writing a better description. None of these events send you a notification by default. The page just changes, silently, and waits for whoever happens to be watching.

Here are three ways to be the person who is watching, from simplest to fully automated.

Before we start: the Delta Tools shortcut for the marketplace version of this problem is our OfferUp Fresh Listing and Price Change Monitor, which watches your OfferUp searches on a schedule and reports only what changed, including price drops, price increases, new listings, and listings that disappeared. It covers OfferUp rather than every store on the internet, and I will be plain about that again later. The rest of this article teaches you to watch any product page by hand, which is the skill that transfers everywhere.

Method 1: Use the trackers and saved searches that already exist (free, minutes)

For the biggest marketplaces, somebody has already built the watcher and gives it away. Your job in this method is simply to find the right one and turn it on properly.

Amazon is the most served store on earth for this. Keepa tracks the price history of Amazon products and can alert you when a price crosses a threshold you set. CamelCamelCamel does the same job with price history charts and drop alerts, and it has done it for years. Both are free for basic use. Both also share the same limit, which is that they only know Amazon. The moment your product lives anywhere else, they know nothing about it.

Marketplaces reward a different habit. On eBay, run your search with the filters you actually care about, save the search, and turn on the email alerts for it. On OfferUp, save the search in the app and allow notifications. New listings then come to you, and when you open the listing you can see the current asking price. What these saved searches do poorly is history. They tell you a listing exists. They rarely tell you that the same listing was $550 last week and is $480 today, because the marketplace shows you the present and quietly forgets the past. Remembering the past is the entire trick of this article, and it is why Method 2 exists.

General page watching services sit between those two worlds. Tools such as Visualping and Distill watch a page or a selected part of a page and notify you when the content changes. They work on almost any store, they need no code, and their free tiers are enough for a handful of pages checked at gentle intervals. Their weakness is that they watch everything on the page, not the price specifically. A rotated banner, a new review count, or a seasonal badge can all trigger a change alert that has nothing to do with money. You will read a few false alarms before you learn to select just the price element, and on some stores the price element moves around too much for that to stay reliable.

When this is enough: you watch a small number of products, they live on Amazon or on a marketplace you already use, and a history chart plus a threshold alert covers what you need.

When it is not: the product lives on a store nobody tracks, you want alerts for a drop of a specific size rather than any change at all, or you watch enough pages that sorting real drops from page noise becomes its own chore. Keep reading.

Method 2: Poll any product page with a script you control (free, works everywhere)

A product page knows its own price, and most stores state that price in several places at once, in formats meant for machines. That fact is what makes a small script reliable enough to trust.

Where the price actually lives on a page

The first place to look is the structured data block. Many stores embed a script block of type application/ld+json in the page head. Inside it, a product is described with fields search engines use, and an offers section usually carries a price field and a priceCurrency field with values such as USD or EUR. This is the cleanest source on the page because the store wrote it for Google, and stores keep it accurate for the same reason you are reading it. Wrong structured data costs them clicks in search results.

The second place is the Open Graph tags in the page head. A meta tag with property product:price:amount carries the price, and a companion tag carries the currency. Stores add these so shared links render nicely in chats and social feeds, and they tend to be current because a stale price in a shared link preview is embarrassing in public.

The third place is microdata in the visible markup. An element with itemprop price, again from the schema.org vocabulary, either holds the price in a content attribute or prints it as text a shopper can read.

The last resort is the visible text itself. The first dollar amount on a page is often the price. It is also often a trap, because pages print installment amounts, accessory prices, and struck through list prices near the real one. The script below tries the three machine readable sources first and only falls back to visible text when nothing else answers. When you adopt it, check the baseline it records for each page once, by eye, so you know which rung of the ladder each of your pages landed on.

The script

The script keeps a watch list of names and page addresses. For each page it fetches the HTML, extracts the price with the ladder above, and compares the result with the price stored in a small JSON state file. A lower price produces an alert line, printed and optionally posted to a webhook so it lands in Slack or Discord or anywhere else that accepts a JSON post. An equal or higher price produces silence, and the new price becomes the reference for the next check.

import json
import os
import re
import urllib.request
from datetime import datetime, timezone

STATE_FILE = "price_state.json"
WEBHOOK_URL = os.environ.get("PRICE_WEBHOOK_URL", "")
MIN_DROP_PERCENT = 0.0

WATCHLIST = {
    "espresso machine": "https://example.com/products/espresso",
    "trail shoes": "https://example.com/products/trailshoes",
}


def fetch_html(url):
    req = urllib.request.Request(
        url,
        headers={"User-Agent": "Mozilla/5.0 price watch script"},
    )
    with urllib.request.urlopen(req, timeout=45) as resp:
        return resp.read().decode("utf-8", errors="replace")


def to_float(raw):
    try:
        return float(str(raw).replace(",", ""))
    except Exception:
        return None


def price_from_node(node):
    if isinstance(node, dict):
        offers = node.get("offers")
        if isinstance(offers, dict):
            raw = offers.get("price")
            if raw is None:
                raw = offers.get("lowPrice")
            if raw is not None:
                return to_float(raw)
        if isinstance(offers, list):
            for offer in offers:
                found = price_from_node({"offers": offer})
                if found is not None:
                    return found
        for value in node.values():
            found = price_from_node(value)
            if found is not None:
                return found
    if isinstance(node, list):
        for item in node:
            found = price_from_node(item)
            if found is not None:
                return found
    return None


def find_price_in_jsonld(html):
    blocks = re.findall(
        r'<script[^>]*type="application/ld\+json"[^>]*>(.*?)</script>',
        html,
        flags=re.S,
    )
    for block in blocks:
        try:
            data = json.loads(block.strip())
        except Exception:
            continue
        found = price_from_node(data)
        if found is not None:
            return found
    return None


def find_price_in_meta(html):
    match = re.search(
        r'property="product:price:amount"\s+content="([\d][\d,]*\.?[\d]*)"',
        html,
    )
    if match:
        return to_float(match.group(1))
    return None


def find_price_in_microdata(html):
    match = re.search(
        r'itemprop="price"[^>]*content="([\d][\d,]*\.?[\d]*)"',
        html,
    )
    if not match:
        match = re.search(
            r'itemprop="price"[^>]*>([\d][\d,]*\.?[\d]*)<',
            html,
        )
    if match:
        return to_float(match.group(1))
    return None


def find_price_in_text(html):
    match = re.search(r"\$\s*([\d][\d,]*\.?[\d]*)", html)
    if match:
        return to_float(match.group(1))
    return None


def extract_price(html):
    finders = (
        find_price_in_jsonld,
        find_price_in_meta,
        find_price_in_microdata,
        find_price_in_text,
    )
    for finder in finders:
        price = finder(html)
        if price is not None:
            return price
    return None


def find_title(html):
    match = re.search(r"<title>(.*?)</title>", html, flags=re.S)
    if match:
        return match.group(1).strip()
    return ""


def announce(line):
    print(line)
    if WEBHOOK_URL:
        payload = json.dumps({"text": line, "content": line}).encode()
        req = urllib.request.Request(
            WEBHOOK_URL,
            data=payload,
            headers={"Content-Type": "application/json"},
        )
        urllib.request.urlopen(req, timeout=30).read()


def main():
    first_run = not os.path.exists(STATE_FILE)
    state = {}
    if not first_run:
        state = json.load(open(STATE_FILE))

    checked = 0
    for name, url in WATCHLIST.items():
        try:
            html = fetch_html(url)
        except Exception as exc:
            print(f"SKIP {name}: fetch failed ({exc})")
            continue
        price = extract_price(html)
        if price is None:
            print(f"SKIP {name}: no price found on page")
            continue
        checked += 1
        old = state.get(url)
        if old is not None and not first_run:
            old_price = float(old["price"])
            if price < old_price:
                drop = old_price - price
                percent = drop / old_price * 100
                if percent >= MIN_DROP_PERCENT:
                    line = (
                        f"PRICE DROP: {name} was ${old_price:,.2f} "
                        f"and is now ${price:,.2f} (down {percent:.1f} percent)"
                    )
                    announce(line + "\n  " + url)
        state[url] = {
            "name": name,
            "price": price,
            "title": find_title(html),
            "checked_at": datetime.now(timezone.utc).isoformat(timespec="seconds"),
        }

    json.dump(state, open(STATE_FILE, "w"), indent=2)
    stamp = datetime.now(timezone.utc).isoformat(timespec="seconds")
    if first_run:
        print(f"{stamp} Baseline built: {checked} prices recorded, none announced.")
        print("Run it again later and only genuine drops will print.")
    else:
        print(f"{stamp} Checked {checked} pages.")


if __name__ == "__main__":
    main()

Three details in that script deserve a callout, because each one bit me before I learned to handle it on purpose.

The first run builds a baseline in silence. If the script announced every price on its first run, you would learn what things cost today, which you already know, and nothing about what changed. So the first run records and stays quiet. From the second run onward, it speaks only when a number moves down. If you edit the watch list later, expect the new pages to join quietly in the same way.

The comparison is against the last price seen, so set a floor for what counts. A seller who trims a price in small steps will trigger an alert at every step, and five alerts about a slow slide from $500 to $460 will teach you to ignore the channel. Set MIN_DROP_PERCENT to 3 or 5 and the script only speaks when a drop is worth your attention. Leave it at zero while you are testing, so you can watch it work on the first small change you can arrange.

The state file is the entire memory, and it is fragile in specific ways. It lives on the machine that runs the script. If that machine is asleep at the scheduled hour, that hour simply never happens. If the file is deleted, the baseline resets and the script goes quiet for one run while it relearns the world. If a page starts failing and returns no price, the script skips it and keeps the old reference, which is the behavior you want, because a store hiccup should never read as a drop to zero. None of this is hard to live with. All of it is yours to live with, on your hardware, forever.

Schedule it with cron on Linux or macOS, or with Task Scheduler on Windows. Hourly checks are a sane default for ordinary shopping. A line like the one below runs the script at the top of every hour and appends its output to a log you can review:

0 * * * * /usr/bin/python3 /home/you/price_watch.py >> /home/you/price_watch.log 2>&1

Be a polite guest while you do this. One request per page per check is a trivial load, and hourly checks on a handful of pages will never trouble a store. Check a page every thirty seconds and you will meet the two status codes that end polite conversations. A 403 means the server understood your request and refuses to answer it. A 429 means you are asking too often, and the correct response is to slow down, not to get clever. Stores also write their rules into their terms, and a personal watcher that fetches a few public pages an hour sits in a very different place from a scraper harvesting a whole catalog. Keep it in the first place.

Set the PRICE_WEBHOOK_URL environment variable to a Slack or Discord webhook and the printed lines become push alerts in a channel you already read. Leave it unset and the log file is your alert feed, which is honestly enough for anything that is not racing other buyers.

If you want the middle ground between building this and forgetting it exists, this is where I should mention the Delta Tools option again, because it exists for the exact moment the script starts feeling like a second job: the OfferUp Fresh Listing and Price Change Monitor runs this same pattern on a schedule for OfferUp searches, with the remembering handled for you.

Method 3: A scheduled monitor for marketplace listings (no infrastructure)

Method 3 is Method 2 with the fragile parts removed, aimed at the place where prices move the most arbitrarily, which is other people and their listings. A store reprices with software and a plan. A person reprices with feelings and a quiet Tuesday. The same couch sits at $300 for a month, then falls to $220 because the seller is moving on Friday. That is the drop worth catching, and it is the drop a saved search alone will never show you, because the marketplace presents the listing as if $220 was always the price.

The monitor is a small Apify actor. You give it searches, and each search names a keyword, a ZIP code, and a radius, with options such as a maximum price and how many listings to scan. On every scheduled run it fetches the current listings, compares them against a snapshot it keeps between runs, and writes only the changes to its output dataset. Each change row carries a type, and the type matters. A price drop row includes the new price, the old price, and the drop as a percent, so you can judge in one glance whether $480 down from $550 deserves your evening. The same run also reports price increases, new listings, edited listings, and listings that disappeared, and a disappearance usually means the item sold, which is information too. Removal is only reported after a listing misses two runs in a row, so a listing that briefly falls out of the results window does not cry wolf.

Give each scheduled monitor its own stateKey if you run more than one, and their memories stay separate. One key for the camera gear near your home, another for the furniture search you run for a friend, no cross talk between them. No OfferUp login is needed, and the actor makes its requests against the public search interface at light volume.

The pricing matches the philosophy of the script. You pay $0.001 when a run starts and $0.005 for each change it reports. A scheduled run that finds nothing new costs the start fee and nothing more. Compare that with scrapers that charge for every row on every run, including the listings you saw yesterday at the same prices. On this design, a quiet week costs you almost nothing, and a busy week costs you pennies in exchange for being early.

Now the honest scope note, because it decides whether this method is yours. The monitor watches OfferUp. It does not watch a retailer product page, and I will not dress it up as if it does. If the thing you want is a specific product on a specific store site, Method 2 is your tool and it is a good one. If the thing you want is whatever the used market near you is repricing this week, the OfferUp Fresh Listing and Price Change Monitor is the version where someone else keeps the lights on, and you just read the feed!

The traps that make price alerts lie

Every method above can be fooled in the same handful of ways. Knowing them is the difference between an alert feed you trust and one you mute by the end of the month.

The price on the page is not always the price you pay. Variants are the classic case. One page sells twelve configurations, the structured data reports the cheapest one, and the configuration you want never moves. If a drop alert sends you to a page and the number looks wrong, check which variant the page opened on before you blame the watcher.

Location changes prices. Stores price by region, by warehouse stock, and sometimes by the shipping address they have guessed from your visit. A script checking from a server in another state can see a different number from the one your browser shows you at home. When a drop matters, confirm it the way you would buy it, signed in and with your own delivery area set.

Some prices only exist in the cart. Coupons applied at checkout, member prices revealed after sign in, and rebates claimed by mail all live below the layer any page watcher can see. Page watching tracks the public price honestly. It cannot track the private arithmetic of a loyalty program, and any tool that promises otherwise is guessing.

A missing price is not a price of zero. When an item sells out, many stores remove the price from the page or replace the offers block entirely. A naive watcher reads that silence as a total collapse and sends the happiest false alert of your week. The script above treats no price found as a skip and keeps the old reference. Whatever you build or adopt, insist on the same behavior.

Pages fight back, politely at first. A store that does not want automated visits will usually start with slow responses, then a 403, then a challenge page that contains no price at all. Your watcher will report skips, which is the signal to slow down or stop for that store, not to escalate. The public web stays public partly because guests behave like guests.

FAQ

How often should I check a product page for a price drop?
Hourly is plenty for almost everything a person buys. Stores and sellers rarely reprice more often than that in ways that matter, and hourly checks keep your request volume trivial. Daily checks are fine for slow categories such as furniture. Save the aggressive intervals for marketplace listings racing other buyers, and even then, think in hours rather than minutes.

What size of drop should trigger an alert?
Start with any drop at all while you learn what normal movement looks like on your pages. After a week or two you will know which of your products jitter by a dollar and which sit frozen for months. Then set a floor, in percent or in plain dollars, that matches what would actually make you buy. An alert you would not act on is noise wearing a costume.

Can I watch pages in other currencies with the script?
Yes, with one small change. The structured data and meta tag rungs of the ladder read plain numbers and ignore the currency entirely, so they already work for euros, pounds, and yen. Only the visible text fallback looks for a dollar sign. Swap that symbol for the one your store prints and the fallback works there too, and the state file will happily store the numbers either way.

Why does my watcher see a different price from my browser?
Usually location, as covered above, and sometimes a signed in member price or a variant the page selected for you. Fetch the page the way a stranger would and you get the stranger price. Neither number is fake. They are answers to different questions, and your watcher answers the public one.

What does the marketplace monitor cost on a quiet week?
Almost nothing, by design. Each run costs $0.001 to start, and each reported change costs $0.005. A daily schedule on a week where nothing changes costs under a cent in start fees. You pay in proportion to how much genuinely changes, which is how monitoring ought to be priced.

Do I need an account or a login to start with the script?
No. The script in Method 2 uses only the Python standard library, runs on any machine that can reach the pages you watch, and stores its memory in a local file you can open and read. The marketplace monitor needs an Apify account to run on a schedule, and no OfferUp login at any point.

How to Track New Job Postings Across Sites With One Alert Feed

Delta Tools — Wed, 14 Oct 2026 15:06:38 +0000

TL;DR: You do not need to refresh five job boards every morning. There are three ways to get every new posting into one place. First, turn on the saved search email alerts inside each board and funnel them into one inbox folder. Second, poll the official APIs of USAJobs and arbeitnow with a short Python script that remembers what it has already seen and prints only what is new. Third, run a scheduled monitor that does the remembering for you. Delta Tools built one for exactly this job. It is called the Job Board New Posting Monitor, and it watches USAJobs and arbeitnow searches and reports only genuinely new postings. All three methods are below, with working code for the second one.

I spent one job hunt doing this the stupid way. Five boards. Five tabs. Every morning I ran the same searches, tried to remember which titles I had already seen, and told myself I was being thorough. I was not being thorough. I was being slow. By the time I found one posting I liked, it had been live for four days, and anyone who applied on day one was already ahead of me in the queue.

Job hunting rewards speed more than almost anyone admits. Recruiters start reading applications while a posting is still gathering them. Some roles close within a week. The edge is not a better resume template. The edge is simply knowing a role exists on the morning it appears, not the morning you happen to check.

Here are three ways to get that edge, from simplest to fully automated.

Before we start: the Delta Tools shortcut for all of this is our Job Board New Posting Monitor, which watches up to 20 searches at once on a schedule and reports only postings it has never shown you before. The rest of this article teaches you to build the same thing by hand, in case you would rather run your own setup.

Method 1: Turn on the alerts each board already gives you (15 minutes, free)

Almost every large board has the same feature hiding under a slightly different name. You run a search, you save it, and the board emails you when new postings match. Most job seekers never turn it on. They bookmark the search results page instead, which is the digital equivalent of walking to the shop every day to see if the bread arrived.

USAJobs is the clearest example, and it is worth doing properly because federal roles have hard closing dates. Sign in, run your search with your keywords and location, and click Save this search above the results. Give it a name and choose how often you want email. Daily is the right choice for anything competitive. USAJobs lets you keep up to 10 saved searches at once, and a saved search expires after one year, so put a note in your calendar to renew the ones that still matter. The notification emails come from notifications@usajobs.gov, and they only list jobs posted since your last email, which means the board is doing the remembering for you on its own turf.

LinkedIn and Indeed offer the same pattern. Run the search, set the filters, and switch on the email alert. The names of the buttons differ. The idea does not.

Now for the part that turns five alert streams into one feed. Create one folder or label in your inbox called Job Alerts. Add a filter rule for each sender address so every alert lands in that folder instead of scattering across your inbox. USAJobs sends from the address above. Indeed and LinkedIn send from their own alert addresses, and you can capture each one from the first email it sends you. From then on, your morning routine is one folder, read once, in date order. Everything new is in there. Nothing requires you to remember what you saw yesterday.

When this is enough: you follow a handful of searches, the boards you care about all have decent alert emails, and you actually read email every morning.

When it is not: the board you need has weak alerts or none at all, you want alerts inside Slack or Discord instead of email, or you follow enough searches that the daily folder becomes its own chore. Keep reading.

Method 2: Poll the official APIs with a script (free, one feed you control)

Two of the most useful boards publish official APIs, and they could not be more different in spirit.

USAJobs runs the official jobs board of the United States federal government. Its API at data.usajobs.gov is free, but it wants a personal API key. You request one on the site, and every request sends that key in a header called Authorization-Key, plus a User-Agent header set to your email address. In return you get structured data with a gift inside it: every posting carries a stable PositionID that never changes for the life of that posting.

arbeitnow is a European board with a large share of English language postings, many of them open to remote work. Its job board API is free and needs no key at all. One GET request to its public endpoint returns a batch of recent postings as JSON, wrapped in a field called data, and you page through older batches by adding a page parameter. It has no search parameter on the server side, so filtering happens on your own machine: you fetch a few pages and keep the postings that match your keyword. Every posting carries a slug, the unique tail of its URL, and that slug is its stable identity.

Stable identity is the whole game. Here is why. You cannot detect new postings by watching the top of a list, because lists move. A posting that sat at position three yesterday sits at position nine today, and a board may edit a title or extend a closing date and push an old posting back into view. If your script compares positions or titles, it will cry wolf constantly, and you will stop reading its alerts within a week. If it compares stable IDs against a set of IDs it has already reported, it stays silent until something genuinely new appears. Dedup is the whole product. Everything else is plumbing.

Here is the whole thing in one script. It checks three pages of arbeitnow and one USAJobs search, prints every posting it has never seen before, and optionally posts each one to a webhook so the alert lands in Slack or Discord or anywhere else that accepts a JSON post.

import json
import os
import urllib.parse
import urllib.request
from datetime import datetime, timezone

SEEN_FILE = "seen_jobs.json"
WEBHOOK_URL = os.environ.get("JOB_WEBHOOK_URL", "")
USAJOBS_KEY = os.environ.get("USAJOBS_API_KEY", "")
USAJOBS_EMAIL = os.environ.get("USAJOBS_EMAIL", "")

ARBEITNOW_API = "https://www.arbeitnow.com/api/job-board-api"
USAJOBS_API = "https://data.usajobs.gov/api/search"


def get_json(url, headers=None):
    req = urllib.request.Request(url, headers=headers or {})
    with urllib.request.urlopen(req, timeout=45) as resp:
        return json.load(resp)


def fetch_arbeitnow(keyword, pages=3):
    found = []
    needle = keyword.lower()
    for page in range(1, pages + 1):
        data = get_json(f"{ARBEITNOW_API}?page={page}")
        items = data.get("data") or []
        if not items:
            break
        for job in items:
            haystack = " ".join([
                job.get("title") or "",
                job.get("company_name") or "",
                " ".join(job.get("tags") or []),
            ]).lower()
            if needle in haystack:
                found.append({
                    "id": "arbeitnow:" + str(job.get("slug") or ""),
                    "title": job.get("title") or "",
                    "company": job.get("company_name") or "",
                    "location": job.get("location") or "",
                    "url": job.get("url") or "",
                })
    return found


def fetch_usajobs(keyword):
    if not USAJOBS_KEY:
        print("USAJobs skipped: no API key set.")
        return []
    params = {
        "Keyword": keyword,
        "ResultsPerPage": "25",
        "Page": "1",
    }
    url = USAJOBS_API + "?" + urllib.parse.urlencode(params)
    headers = {
        "Host": "data.usajobs.gov",
        "Authorization-Key": USAJOBS_KEY,
        "User-Agent": USAJOBS_EMAIL,
    }
    data = get_json(url, headers=headers)
    found = []
    for item in data.get("SearchResultItems") or []:
        d = item.get("MatchedObjectDescriptor") or {}
        job_id = d.get("PositionID") or item.get("MatchedObjectId")
        if not job_id:
            continue
        found.append({
            "id": "usajobs:" + str(job_id),
            "title": d.get("PositionTitle") or "",
            "company": d.get("OrganizationName") or "",
            "location": d.get("PositionLocationDisplay") or "",
            "url": d.get("PositionURI") or "",
        })
    return found


def announce(job):
    line = f"NEW: {job['title']} at {job['company']} ({job['location']})\n  {job['url']}"
    print(line)
    if WEBHOOK_URL:
        payload = json.dumps({"text": line}).encode()
        req = urllib.request.Request(
            WEBHOOK_URL, data=payload,
            headers={"Content-Type": "application/json"},
        )
        urllib.request.urlopen(req, timeout=30).read()


def main():
    first_run = not os.path.exists(SEEN_FILE)
    seen = set()
    if not first_run:
        seen = set(json.load(open(SEEN_FILE)))

    jobs = fetch_arbeitnow("software engineer") + fetch_usajobs("data analyst")

    new_jobs = [j for j in jobs if j["id"] not in seen]
    for job in new_jobs:
        if not first_run:
            announce(job)

    seen.update(j["id"] for j in jobs)
    json.dump(sorted(seen), open(SEEN_FILE, "w"))

    stamp = datetime.now(timezone.utc).isoformat(timespec="seconds")
    if first_run:
        print(f"{stamp} Baseline built: {len(jobs)} postings recorded, none announced.")
        print("Run it again tomorrow and only genuinely new postings will print.")
    else:
        print(f"{stamp} Checked {len(jobs)} postings, {len(new_jobs)} new.")


if __name__ == "__main__":
    main()

Three details in that script deserve a callout, because each one cost me a round of duplicate alerts before I learned it.

The first run builds a baseline in silence. If the script announced everything on its first run, you would get a flood of postings that have been sitting there for weeks, and half of them would already be closed to serious competition. So on the first run it records what exists and announces nothing. From the second run onward, it announces only IDs it has never recorded. If you would rather see the full list once, announce on the first run too. Just know what you are asking for.

The seen file is the entire database, and it is fragile in specific ways. It lives on the machine that runs the script. If that machine is asleep at the scheduled hour, that hour simply never happens. If the file gets deleted, the baseline resets and the flood returns. If the script crashes after announcing a posting but before saving the file, you will hear about that posting twice. None of this is hard to fix. All of it is yours to fix, forever, at 11 p.m. on a Sunday.

Keyword matching on arbeitnow is honest but blunt. Because the API has no server side search, the script fetches recent pages and matches your keyword against the title, the company name, and the tags. Postings that describe your role with a synonym you did not pick will slip past. Run two or three keyword variants if the role has more than one common name. And keep the page count modest. arbeitnow gives this API away for free and asks callers not to abuse it, and three pages every hour is well inside polite territory.

Schedule it with cron on Linux or macOS, or with Task Scheduler on Windows, every hour or two during the hours you care about. Set the JOB_WEBHOOK_URL environment variable to a Slack or Discord webhook and the prints become push alerts in a channel you already read. Set USAJOBS_API_KEY and USAJOBS_EMAIL and the federal postings join the same feed. One feed. One place to look.

If you want the middle ground between Methods 1 and 2, this is also where I should mention the Delta Tools option again, because it exists for the exact moment the script starts feeling like a second job: the Job Board New Posting Monitor runs this same pattern on a schedule, with the remembering handled for you.

Method 3: A scheduled monitor that handles the boring parts (no infrastructure)

Method 3 is Method 2 with the fragile parts removed. The monitor is a small Apify actor. You give it your searches, up to 20 in a single run, and each search names a source, USAJobs or arbeitnow, plus a keyword and its own options. USAJobs searches accept a location and a freshness window, so your first run can ignore postings older than seven days instead of drowning in history. arbeitnow searches accept a location filter and a remote only switch. You paste in your free USAJobs key if you use federal searches. arbeitnow needs no key at all, and if you leave the key out, the USAJobs searches skip gracefully while the arbeitnow searches still run.

On every scheduled run it fetches the current postings, compares stable IDs against a snapshot it keeps between runs, and writes only the genuinely new ones to its output dataset. Each row carries the title, the company, the location, the posting date, and a direct link, tagged with the search that found it. It can also report postings that disappeared, which matters more than it sounds: a posting vanishing inside its window usually means the role was filled or pulled, and knowing that stops you polishing an application for a door that already closed. Rows about removed postings are never billed.

The pricing matches the philosophy. You pay $0.001 when a run starts and $0.0015 for each genuinely new posting it delivers. A scheduled run that finds nothing new costs the start fee and nothing more. Compare that with scrapers that charge for every row on every run, including the ninety percent of rows you saw yesterday. On this design, a quiet week costs you almost nothing, and a busy week costs you pennies in exchange for being early.

The output dataset plugs into the rest of your life through Apify integrations and webhooks, so new postings can land in Slack, in email, or in a Google Sheet you share with a friend who is hunting for the same roles. Give each scheduled monitor its own stateKey if you run more than one, and their memories stay separate. One key for your own search, another for the contract roles you track for a client, no cross talk between them.

I will not pretend the script in Method 2 is a lesser choice. It is free, it is transparent, and the code above is yours to keep and change. Plenty of people should run the script. The actor exists for people who have noticed that their laptop sleeps, their cron file does not survive a new machine, and their seen file is one careless cleanup away from a Monday morning flood. The Job Board New Posting Monitor is the version where someone else keeps the lights on, and you just read the feed!

FAQ

How often should I check for new postings?
Hourly during waking hours is plenty for most roles. Federal postings on USAJobs usually stay open for days or weeks, so even a daily check beats the crowd there. Competitive commercial roles can gather a full slate of applicants fast, and for those, hourly checks on a schedule beat a daily email digest.

Can I watch more than one board in a single feed?
Yes, and that is the point of this article. Method 1 funnels the alert emails of several boards into one inbox folder. Method 2 merges arbeitnow and USAJobs into one printed or webhooked feed. Method 3 runs up to 20 searches across both sources in a single scheduled run and merges the results into one dataset.

Why not just scrape LinkedIn or Indeed?
Because you do not need to, and the ground there is genuinely hostile. Both platforms work hard to block automated collection, and accounts get restricted for it. The boards in this article publish official APIs that hand you the same postings in structured form, with stable IDs made for exactly this job. Use the door the owner built.

What does new actually mean in these methods?
It means an ID your system has never recorded before. Not a posting near the top of a list. Not a posting with an edited title. A stable posting ID, a PositionID on USAJobs or a slug on arbeitnow, appearing for the first time in your snapshot. That definition is what keeps the feed quiet on ordinary days and loud only when it should be.

How much does the monitor cost on a quiet week?
Almost nothing, by design. Each run costs $0.001 to start, and new postings cost $0.0015 each. A daily schedule on a week where nothing matches costs under a cent in start fees. You pay in proportion to how much genuinely new material shows up, which is how monitoring ought to be priced.

Do I need an API key to start?
Only for USAJobs, and that key is free from data.usajobs.gov. arbeitnow needs no key, no account, and no setup, so you can run the script in Method 2 against arbeitnow in the next five minutes and add the federal feed whenever you are ready.

How to Monitor SAM.gov for New Contract Opportunities Without Checking Daily

Delta Tools — Wed, 07 Oct 2026 15:31:04 +0000

TL;DR: A Congressional Research Service report states that when a federal contract is expected to exceed $25,000, the agency posts the solicitation on SAM.gov. There are three ways to watch those postings without refreshing the site every morning: SAM.gov's own saved search email alerts (free, but thin), a Python script that polls SAM.gov's public search API (free, real routing control), or a scheduled monitor that handles dedup and alerting with no infrastructure (our SAM.gov New-Opportunity Monitor is built for this). All three methods are below, with working code.

I once watched a small IT services firm lose a bid they were perfect for because someone found the solicitation with three days left on the response window. Not three days after it posted. Three days before responses were due. The notice had been sitting on SAM.gov for six weeks.

That is the entire problem in one story. The federal government posts thousands of contract opportunities, and the difference between winning and never knowing a contract existed is usually just timing. Small contractors and boutique govcon shops cannot afford a full time person refreshing SAM.gov every morning. So they check when they remember, which means they miss things.

Here are three ways to fix that, from simplest to fully automated.

Before we start: the Delta Tools shortcut for all of this is our SAM.gov New-Opportunity Monitor, which watches keyword searches on a schedule and reports only genuinely new notices. The rest of this article teaches you to do the same thing by hand, in case you would rather run your own setup.

Method 1: SAM.gov saved searches with email alerts (10 minutes, free)

This is the feature most people walk right past. SAM.gov has saved searches, and saved searches for Contract Opportunities have a Notify option that emails you when new matches appear. This is documented in the GSA Federal Service Desk knowledge base, and it is the only SAM.gov domain where the notify feature exists.

Here is how to set it up:

Sign in to SAM.gov (you need an account for this; anonymous visitors can search but cannot save).
Run a Contract Opportunities search for your keywords.
Click the Actions button in the upper right, then Save. Give the search a name.
Go to Saved Searches (from the search results page or your Workspace).
Click the Actions menu next to your saved search and select Notify.

That is it. On any day your search has new results, SAM.gov sends an email to your registered address. An Army Corps of Engineers guidance document notes these notifications go out once daily at 9 p.m. Eastern.

Two honest caveats. First, the email is just a link to your saved search. It does not tell you what matched, how many notices matched, or whether any of them are worth your time. You click, you log in, you read. Second, the daily cadence means a solicitation with a short response window can burn most of its fuse before you see it.

When this is enough: you have one or two keyword searches, you check email every morning anyway, and your targets are mostly Solicitations and Combined Synopsis/Solicitations with normal response windows. For a lot of small firms, this genuinely covers it.

When it is not: you want routing control (Slack, a shared inbox, a webhook into your CRM), you want alerts faster than once a day, or you watch enough searches that the daily link click becomes its own chore. Keep reading.

Method 2: Poll the public search API with a script (free, real control)

SAM.gov's search page is powered by a public, unauthenticated search API. No API key, no login, no proxy. The endpoint looks like this:

https://sam.gov/api/prod/sgs/v1/search/

It takes query parameters. The ones that matter: index=opp (the Contract Opportunities index), q (your keyword), qMode=ALL (mandatory, without it the keyword is silently ignored), size (how many results, between 10 and 1000), and sort=-modifiedDate (newest first).

A quick warning before the code, because this is the kind of thing that bites people. The sort is by modified date, not publish date. A notice amended this morning sorts as "newest" even if it was originally published four months ago. So you cannot diff by position or by date. You must diff by notice ID. Dedup is the whole product here, same as it is in every monitor I have ever built.

Here is the whole thing in about 40 lines:

import json, os, urllib.parse, urllib.request

API = "https://sam.gov/api/prod/sgs/v1/search/"
SEEN_FILE = "samgov_seen_ids.json"
HEADERS = {"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"}

def search(keyword, size=50):
    params = {
        "index": "opp",
        "q": keyword,
        "qMode": "ALL",
        "page": "0",
        "size": str(size),
        "mode": "search",
        "sort": "-modifiedDate",
        "is_active": "true",
    }
    url = API + "?" + urllib.parse.urlencode(params)
    req = urllib.request.Request(url, headers=HEADERS)
    with urllib.request.urlopen(req, timeout=45) as resp:
        return json.load(resp)

def main():
    seen = set(json.load(open(SEEN_FILE))) if os.path.exists(SEEN_FILE) else set()

    data = search("cybersecurity")
    results = data.get("_embedded", {}).get("results", [])
    new_notices = []

    for item in results:
        notice_id = str(item.get("_id") or "")
        if notice_id and notice_id not in seen:
            new_notices.append({
                "id": notice_id,
                "title": item.get("title") or "",
                "solicitation": item.get("solicitationNumber") or "",
                "url": f"https://sam.gov/opp/{notice_id}/view",
            })

    for n in new_notices:
        print(f"NEW: {n['title']} ({n['solicitation']})\n  {n['url']}")
        # send_to_slack(f"New SAM.gov opportunity: {n['title']}\n{n['url']}")

    seen.update(str(item.get("_id") or "") for item in results)
    json.dump(sorted(seen), open(SEEN_FILE, "w"))
    print(f"Checked {len(results)} notices, {len(new_notices)} new.")

if __name__ == "__main__":
    main()

Run it on a cron every hour or two. The samgov_seen_ids.json file is your entire database. Wire the send_to_slack line to Slack, Discord, email, or an SMS gateway and you have real push alerts routed wherever your team actually looks.

A few things worth knowing before you scale this up:

Watch Sources Sought notices, not just Solicitations. SAM.gov notice types include Solicitation (o), Combined Synopsis/Solicitation (k), Presolicitation (p), Sources Sought (r), Special Notice (s), and Award Notice (a). Sources Sought notices are presolicitation market research. Responding early with a capability statement puts you on the agency's radar before the formal solicitation exists, and most of your competitors will never know the opportunity was brewing. Several govcon coaches specifically advise filtering for these.

Do not trust server side NAICS filtering on this API. In testing, NAICS and set aside parameters on the frontend search API silently fail open, meaning you get results outside your filter without any error. Keyword search is fully server side and reliable; notice type filtering is safest done client side after you fetch. And remember that contracting officers assign NAICS codes inconsistently. A well known example in govcon circles: an IT contract might land under 541512 one week and 541519 the next. Search adjacent codes or just use broad keywords.

The script's real fragility is operational, not technical. One search is easy. Ten searches means ten state files, ten cron entries, and ten chances for a crash between "detect new notice" and "save state" to produce either duplicate alerts or a missed one. Move machines and the state files do not come with you. I built method 3 because I got tired of babysitting exactly this.

Method 3: A scheduled monitor that handles the boring parts (no infrastructure)

This is the version I run now: a small Apify actor that watches SAM.gov keyword searches on a schedule and reports only genuinely new notices. You configure up to 20 searches per run, each with a keyword, an active only toggle, a result cap, and optional notice type filters. On each run it fetches the newest results, diffs by notice ID against a persisted snapshot, and outputs only notices it has never seen before. Amendments to notices you have already seen are not reported again.

The output is a structured dataset per new notice: title, solicitation number, notice type, agency, office, publish date, response due date, and a direct sam.gov/opp/<id>/view link. New results land in an Apify dataset, which you can wire to Slack, email, Google Sheets, or webhooks through Apify's integrations. A scheduled check that finds nothing new outputs an empty dataset and costs almost nothing.

The SAM.gov New-Opportunity Monitor is priced per new opportunity: $0.001 per run start plus $0.0025 per genuinely new notice reported. A quiet daily run costs a fraction of a cent. You pay when there is something worth your attention, not for every notice scanned.

I will not pretend it is the only way to do this. Method 2 is genuinely fine if you like running your own infrastructure, and the code above is yours to keep. The actor exists for people who would rather set a schedule once and get pinged, with no cron jobs, no state files, and no "the laptop was asleep" gaps.

Which method should you pick?

One or two searches and you live in email? Method 1. Saved searches with Notify, ten minutes, free, done.
Want push alerts and routing control and do not mind a little ops? Method 2. The script above, a cron job, somewhere always on.
Want alerts with zero infrastructure and clean dedup? Method 3. Set it once, get pinged only when something is actually new.

FAQ

Do I need a SAM.gov account?
Only for method 1. Saved searches and the Notify feature require a login. Methods 2 and 3 use the public search API, which needs no key and no login.

How fast are the alerts?
Method 1 sends one email per day on days your saved search has new results. Method 2 runs at whatever interval your cron uses; hourly or every two hours is polite and more than fast enough. Method 3 runs on your Apify schedule, hourly or daily.

Will SAM.gov block the API polling?
At reasonable intervals, no. The frontend API powers SAM.gov's own search box, and a query every hour or two is nothing compared to normal site traffic. Do not poll every minute from multiple IPs; that is how you get rate limited anywhere.

Does this catch amendments to notices I already saw?
By design, no. The API sorts by modified date, so an amended notice looks "newest," but both the script and the actor diff by notice ID, which means each notice is reported exactly once. If you need amendment tracking, use SAM.gov's Follow feature on individual notices.

Should I watch Award Notices too?
Yes, as competitive intelligence. Award notices tell you who won what and at what price, which feeds your pricing strategy for the next round. They also reveal which agencies are actively buying what you sell.

Can I watch multiple keywords at once?
Method 1: one saved search per keyword set. Method 2: loop the search() function over a list of keywords and keep one state file per keyword (or namespace the IDs). Method 3: the input takes up to 20 searches in a single run.

If you would rather not babysit a script, the SAM.gov New-Opportunity Monitor is method 2 as an actor: up to 20 keyword searches on a schedule, routed to Slack or email, and you only pay when it finds something genuinely new. Set it once and stop worrying about the 9 p.m. email lottery!

How I Built a Substack New-Post Monitor (and the Dedup Problem Nobody Warns You About)

Delta Tools — Sun, 04 Oct 2026 00:33:16 +0000

TL;DR: Fetching a Substack publication's latest posts took an afternoon. Making the monitor not alert twice on the same post — across runs, crashes, and machine moves — was the actual project. Here's the naive version, the three ways it broke, and the dedup design that finally held. The finished tool is our Substack New-Post Monitor on the Apify Store.

The naive version (afternoon one)

The job sounded trivial: watch a Substack publication, tell me when a new post appears. Substack even hands you the data — every publication has an RSS feed at <publication>.substack.com/feed. Parse it, compare against last time, alert on the difference.

import feedparser

feed = feedparser.parse("https://example.substack.com/feed")
latest = feed.entries[0]
print(f"Latest: {latest.title} — {latest.link}")

Done, right? It printed the latest post. I wired it to a Slack webhook, set a 15-minute cron, and felt extremely productive for about a day.

Then the double alerts started.

Break #1: "What did I already see?" has no obvious home

The first version kept seen_ids.json next to the script. It worked until I moved the script to a different machine and every post re-alerted — the state file didn't come along. Then I forgot the file on a deploy and got a fun burst of "NEW POST" messages for articles from 2023.

The lesson: the state file is the product, and it needs to live where the compute lives. On Apify, that meant a named key-value store shared across scheduled runs — state travels with the actor, not with my laptop. Anywhere else, it means a real database or at minimum a state file on the same always-on host as the cron job, backed up.

Break #2: The crash between "detect" and "save"

This one was subtler. The original loop was:

Fetch feed
Diff against seen IDs
Send alerts for new posts
Save updated seen IDs

If the process died between 3 and 4 — machine reboot, OOM kill, deploy — the next run re-detected the same posts and re-alerted. I "fixed" it by saving state before sending alerts, which flipped the failure mode: crash between save and alert meant silently missing posts, which is worse. A missed alert is invisible; a duplicate is just annoying.

The correct order is a tiny transaction: fetch → diff → persist the new seen-set first → send alerts → if alerting fails, the next run sees the posts as already-seen... no wait, that drops them again.

What actually works: persist seen IDs and a pending-alerts queue atomically, then drain the queue. On startup, drain any leftover queue before doing new work. It's a miniature outbox pattern, and yes, it's overkill for a side project — until the one time your 3am deploy eats the alert for the post you were actually waiting for.

For the Apify version, the platform's dataset + key-value store gives atomic-ish primitives that make this straightforward. The principle is the same anywhere: never let "I noticed it" and "I told someone" be separable without a recovery path.

Break #3: Identity is harder than it looks

What identifies "the same post" across polls? My first attempt used the post URL. Fine — until Substack's feed briefly served a post with a different canonical URL during an update, and it re-alerted. Then I tried titles; Substack authors edit titles, and every edit re-alerted.

RSS entries have GUIDs (entry.id in feedparser), which are supposed to be stable identifiers. They mostly are. My prototype scheme: GUID primary, URL as fallback, and never the title. Two identifiers agreeing beats one identifier you trust.

The shipped version simplified this further: Substack's archive API hands you stable post IDs, so the dedup key is just the post ID. Same principle, less machinery.

What the finished actor does

The Substack New-Post Monitor on the Apify Store is this design, packaged:

You give it a publication URL and a schedule. It fetches via Substack's public archive API, dedups on Substack's stable post IDs, persists its snapshot in a named key-value store (shared across scheduled runs — the lesson from Break #1, applied), and emits only genuinely new posts to the output dataset.
New posts land in the dataset ready to wire to alerts via Apify webhooks; a check that finds nothing costs a fraction of a cent.
It passed 7/7 of my stress tests: duplicate suppression across runs, crash recovery, multi-publication state isolation, feed hiccups.

I'm not claiming it's the only way to do this. The 20-line script from my alerts tutorial plus a seen_ids.json on a Raspberry Pi is a completely legitimate setup — I ran exactly that for weeks. The actor is for when you'd rather not be the ops team for your own alerts.

The real lesson

Every "monitor X for changes" tool is two tools: a fetcher (afternoon) and a rememberer (the actual project). The fetcher is the demo. The rememberer is the product. If you're building any kind of change-detection — price trackers, job alert bots, listing monitors — budget your time accordingly: 20% fetching, 80% state, identity, and crash recovery.

FAQ

Why not just use Substack's email subscriptions?
They work, but they're inbox-bound and all-or-nothing per publication. A monitor routes to Slack/Discord/webhooks and watches without subscribing.

Does it handle paid publications?
Only public/free posts via the public feed — same limitation as any RSS-based approach. Paywalled content needs an authenticated session, which is a different tool.

How much does it cost to run?
On Apify's pricing: a scheduled check that finds nothing costs a fraction of a cent. You pay meaningfully only when there's actually a new post to report. (Exact numbers depend on Apify's current compute pricing.)

Could I build this myself?
Absolutely — the tutorial version is 20 lines plus a state file. Build it if you enjoy the ops; use the actor if you don't.

How to Get Notified When a Substack Publication Posts Something New

Delta Tools — Sun, 04 Oct 2026 00:30:36 +0000

TL;DR: Every Substack publication has a hidden RSS feed at publicationname.substack.com/feed. You can watch it with an RSS reader, poll it with a 20-line Python script, or — if you want alerts without running infrastructure — use a scheduled monitor like our Substack New-Post Monitor. Below are all three methods, working code included.

I follow about a dozen Substack publications. For months my system was "remember to check them," which is to say I missed half of everything. Substack has email subscriptions, but I didn't want a dozen newsletters clogging my inbox — I wanted a ping only when something new went live, routed where I actually look.

There are three solid ways to do this. They go from simplest to most automated.

Method 1: The hidden RSS feed + a reader (2 minutes, free)

This is the thing most people don't know: every Substack publication exposes an RSS feed at:

https://<publication>.substack.com/feed

So if you follow stratechery.substack.com, the feed is https://stratechery.substack.com/feed. It contains the latest posts with titles, links, and timestamps. It just works — no API key, no scraping.

Point any RSS reader at it (Feedly, Inoreader, NetNewsWire, even an old-school reader). You'll see new posts alongside everything else you follow. Zero code, zero cost.

Downside: it's pull, not push. You see new posts when you open the reader, not the moment they go live. If "the moment it happens" matters — job alerts, deal alerts, time-sensitive analysis — keep reading.

Method 2: Poll the feed with a script (20 lines of Python)

If you want actual notifications (Slack, Discord, email, SMS), poll the feed on a schedule and diff against what you've already seen. Here's the whole thing:

import feedparser, json, os, time

FEED_URL = "https://example.substack.com/feed"
SEEN_FILE = "seen_ids.json"

seen = set(json.load(open(SEEN_FILE))) if os.path.exists(SEEN_FILE) else set()

feed = feedparser.parse(FEED_URL)
new_posts = [e for e in feed.entries if e.id not in seen]

for post in new_posts:
    print(f"NEW: {post.title} — {post.link}")
    # send_to_slack(f"New post: {post.title}\n{post.link}")

seen.update(e.id for e in feed.entries)
json.dump(sorted(seen), open(SEEN_FILE, "w"))

Run it on a cron every 15 minutes. The seen_ids.json file is the entire "database" — and it's also the entire point. Dedup is the whole product. Without remembering what you've already seen, every poll re-alerts on the same posts. With it, you get exactly one alert per new post.

This works fine for one or two publications on a machine that's always on (a Raspberry Pi, a cheap VPS, or just your laptop if you don't mind it sleeping through alerts).

Downsides at scale: run it for ten publications and you're managing ten cron jobs and ten state files. Move machines and the state file doesn't come with you — hello, duplicate alerts for everything. And if the script crashes between "detect" and "save state," you either miss posts or double-alert. I learned all of this the annoying way, which is why method 3 exists.

Method 3: A scheduled monitor that handles the boring parts (no infrastructure)

This is what I ended up building: a small Apify actor that watches a Substack publication and reports new posts. You give it the publication URL and a schedule. New posts land in the output dataset, which you can wire to Slack, email, or webhooks through Apify's integrations — no cron jobs or state files to babysit. A check that finds nothing new costs a fraction of a cent.

The Substack New-Post Monitor is the one I run myself. One job per tool, priced per result — a scheduled check that finds nothing new costs almost nothing.

I'm not going to pretend it's the only option. If you like running your own infra, method 2 is genuinely fine and the code above is yours to keep. The actor exists for people who'd rather not babysit cron jobs and state files.

Which method should you pick?

Just want to read new posts in one place? Method 1. RSS reader, done in two minutes.
Want push alerts and don't mind a tiny bit of ops? Method 2. The script above, a cron job, somewhere always-on.
Want alerts with zero infrastructure? Method 3. Set it once, get pinged.

FAQ

Does this work for paid Substack publications?
The public /feed only includes free posts. Paid-only content behind the paywall isn't in the public feed — for that you'd need to be subscribed and logged in, which is a different (harder) problem.

How fast are the alerts?
Method 1 is whenever you open your reader. Method 2 is your cron interval (15 minutes is polite; don't hammer it every 60 seconds). Method 3 runs on whatever schedule you set.

Will Substack block polling?
At reasonable intervals (every 10–15 minutes), no. It's a standard RSS feed designed to be polled. Don't poll every minute from five IPs — that's how you get rate-limited anywhere.

Can I watch multiple publications at once?
Method 1: add multiple feeds to the reader. Method 2: loop over a list of feed URLs (one state file per publication, or namespace the IDs). Method 3: the actor's input takes a list of publications in a single run.

What about Substack's own email notifications?
They work, but they're all-or-nothing per publication and they land in your inbox mixed with everything else. These methods give you routing control — Slack, Discord, webhook, SMS — and let you watch publications without subscribing to their emails.