DeepSeek Harness plugin data API
Structural verification results for 719 plugins, served as static JSON. If you are building a plugin marketplace, a CLI, or an agent tool, you do not need your own crawler and verifier — read this instead.
Why this exists
The GitHub dsh-plugin topic carries over 3,000 repositories, but sampling shows most of them declare no dsh.bundle at all — a hot topic attracts unrelated projects. Crawling it treats noise as plugins.
The npm keyword index is far cleaner but still cannot tell you whether a plugin will break on install. Whether the declared patch actually shipped, whether a row points at the author’s own disk, whether the browser half is missing — only the tarball knows.
This API pulls every tarball daily, runs seven checks, and compares each dependency range against what npm ships today. 38 plugins are pinned to a range that has moved on — no social signal reveals that.
Endpoints
All GET, all static, no auth and no rate limit, with Access-Control-Allow-Origin set to *. Nothing breaking changes inside the v1 prefix; fields are added, never removed.
/api/v1/meta.json2 KBEndpoint list, schema version, counts, and field documentation.
/api/v1/stats.json1 KBEcosystem totals: installable, verified, compatibility spread, per-category and per-day counts.
/api/v1/index.json290 KBEvery plugin as a compact row — the listing payload, with single-letter keys documented in meta.json.
/api/v1/plugins.json3.4 MBThe full corpus: every check result, patch row, compatibility finding, and npm and GitHub fact.
/api/v1/plugins/{packageName}.json~4 KBOne plugin. Scoped names nest, so @scope/name lives at /plugins/@scope/name.json.
/api/v1/verified.json20 KBNames that pass all seven structural checks — the allowlist, if you want one.
/api/v1/stale.json8 KBPlugins whose declared dsh dependency range no longer admits the published version, with the offending ranges.
Using it
For a marketplace: fetch the listing
const res = await fetch('https://dshplugins.co/api/v1/index.json')
const { plugins, generatedAt } = await res.json()
// v = passes every structural check, x = dependency compatibility
const safe = plugins.filter((p) => p.v && p.x !== 'stale')For a CLI: check one before installing
const name = '@liustack/modlens'
const res = await fetch(`https://dshplugins.co/api/v1/plugins/${name}.json`)
if (res.status === 404) return { known: false }
const { plugin } = await res.json()
const failed = plugin.checks.filter((c) => !c.ok)
// plugin.install.warnsAllowBuilds === true means installing runs
// the package's build script on the user's machine.If you only want an allowlist
curl -s https://dshplugins.co/api/v1/verified.json | jq '.plugins | length'The data is CC BY 4.0. Attribute it and link back — there is nothing to apply for and nothing to pay. If you find a wrong result, open an issue; the pipeline reruns daily.
What this data does not tell you
It reads packaging, not code. A plugin passing all seven checks can still be malicious, useless, or simply bad. Treat it as a dead-on-arrival filter, not a safety endorsement — a plugin runs inside the dsh process with everything dsh can reach.