How to Track Chrome Web Store Changes: Permissions, Versions, and New Entrants

An extension listing is a moving target

Most people treat the Chrome Web Store like a directory: look up an extension, read its permissions, check the install count, move on. That works for a single snapshot, but it hides the part that actually matters for security, competitive, and market research. Listings change. An extension can add a host permission in a routine version bump, start collecting data it did not collect last month, get pulled from the store, or double its user base without any announcement.

If you export the catalog once, you have a photograph of a thing that keeps moving. The moment you save the file, it starts drifting from reality. The fix is to stop thinking in exports and start thinking in change feeds: record the current state, then record only what changes after that.

That is how Crawlora's Chrome Web Store dataset (chrome_extensions_v1) is built. It covers 314,807 active listings, crawled July 2026, refreshed daily for the highest-adoption tier and weekly for the full catalog. Crucially, it stores change-only history. A new history point is written for an extension only when one of its tracked fields changes, so the timeline you read is signal, not a wall of identical daily snapshots.

What the change feed tracks

Eight fields are watched per listing. Each one answers a different research question.

Change type	Why it matters
status	New listing or removal. This is your new-entrant and takedown signal: catching an extension appear in a category, or disappear from the store entirely, without polling every page.
version	A version bump marks a release. The cadence tells you how actively an extension is maintained, and a version change is often the moment other fields (permissions, privacy) move with it.
permissions	An update that adds host access or a sensitive permission is a security signal. Permission drift on an extension you already trust is a classic supply-chain risk, worth an alert.
privacy	Data-safety declarations. A change here means the developer now declares different data collection or use. New collection on an installed extension deserves a second look.
users	Adoption. Growth or decline in the displayed install count, useful for competitive tracking, though bucketed by Google (see the caveat below).
rating	The average score. A sustained drop can flag a bad release, a policy change users dislike, or review-bombing.
rating_count	Review volume. Rising counts show engagement and momentum; the pace of new reviews is a cleaner adoption proxy than the bucketed install number.
developer	The listed publisher. A developer change can mean an extension was sold or transferred, which is a well-known precursor to permission and privacy changes.

Three workflows

1. Security and supply-chain monitoring

Pick the set of extensions your organization allows, then watch them for the two change types that matter most: permissions and privacy. A new host permission or a new data-collection declaration on an extension your team already installed is exactly the kind of quiet change that a one-time review will never catch.

Poll /changes?change_type=permissions (and change_type=privacy) on a schedule, scoped to the item IDs you care about. For a full picture of any single extension, /history/{id} returns its complete timeline, so you can see when a permission was added and whether a developer change preceded it. To find your candidate set in the first place, /search filters by permission and collects_data directly.

2. Competitive tracking

To follow a rival, watch version and the adoption fields. /history/{id} gives you their release cadence: how often they ship, and whether shipping correlates with rating movement. /search?developer=... pulls a competitor's full portfolio so you are tracking every listing they own, not just the one you already knew about. /trending surfaces the fastest movers by a trend score if you want to know who is gaining ground in a category before it is obvious.

3. Discovery of new entrants and removals

The status change type is your discovery lane. New listings appearing in a category tell you who just entered the market; removals tell you what got pulled. Combine /search?category=... to define the space with /changes?change_type=status to catch entrants and exits as they happen. /facets gives you the aggregate distributions (by category, permission, manifest version) so you can see how the shape of a category shifts over time, and /metrics returns chart-ready totals for a dashboard.

A worked micro-example

Here is what a single adoption change looks like in the feed. In the observed window, the game extension "Flappy Bird Offline" moved from a displayed 100,000 installs to 200,000, a users change of +100,000. In the feed that is one history point: the item ID, the field that changed, the old value, and the new value. You could catch it with /changes?change_type=users, or read it in context on that extension's /history/{id} timeline alongside any version or rating changes around the same time.

That example also shows the limit you have to design around.

Getting started

Everything above is reachable over REST and MCP. /datasets/chrome-extensions/search filters the catalog by permission, collects_data, min_users, category, developer, item_type, manifest_version, and status. /facets returns aggregate distributions, /trending returns the fastest movers, /changes returns recent change events filterable by change_type, /history/{id} returns one item's full timeline, /metrics returns chart-ready totals, and /items/{id} returns the current record. Point a scheduled job at /changes for the change types you care about, and you have a monitor instead of a stale export.

Monitor the Chrome Web Store, don't re-crawl it

Track permission, privacy, version and status changes across 314,807 listings with a change feed, trending and per-item history. REST and MCP, 2,000 free credits a month, no card.

Explore the datasetRead the MCP docs