HALOWERK paketwerk

Endpoints (14 live)

• POST /v1/artifact-hash — Takes a file digest and answers which released package version it is. Useful for an artefact found in a container layer, a build directory or an attachment with no metadata attached. Hex and base64 input are both accepted and normalised, the digest length is checked against the declared algorithm before anything is fetched, and the response names every matching package version, since one artefact can be published under more than one coordinate. (0.003 USDC on Base)
• POST /v1/package-versions — Returns the full version history of a package from a single normalised schema that covers seven ecosystems. Versions are ordered by semantic version, not alphabetically and not in registry order, so 1.10.0 sorts after 1.9.0 — the mistake that quietly breaks naive comparisons. For each version you get the publication timestamp, whether it is the registry default, whether it is deprecated and the deprecation reason as the registry states it. (0.003 USDC on Base)
• POST /v1/release-cadence — Looks at when a package published, not how often, and reports where the pattern breaks. Three kinds of finding, which mean different things and are kept apart. A long gap: a silence several times the package own median interval, which suggests dormancy. A burst: several releases inside a short window, which is either emergency fixes or an automated publish loop that ran away, and the response gives the dates so the reader can tell. (0.004 USDC on Base)
• POST /v1/package-match — Resolves a package to the source projects it declares, with the provenance of each link stated. This is the honest way to answer whether two packages belong together: names repeat across ecosystems and mean different things there, and that gap is exactly what dependency confusion attacks aim at. (0.004 USDC on Base)
• POST /v1/dependency-confusion — Takes the names your organisation publishes internally and checks each against the public registry of the same ecosystem. Three findings, kept apart because they call for different actions. Name is free: nobody has taken it, the door is open but unattended, and the answer is to reserve the name yourself. Name is taken and old: probably an unrelated project that happens to share the name, worth confirming but rarely urgent. (0.005 USDC on Base)
• POST /v1/package-freshness — Turns the release history of a package into a maintenance signal an agent can act on. Four measurements go in: the age in days of the newest stable release, the median gap between the last ten releases, the ratio of the current silence to that median, and whether the newest version is deprecated. Each maps to a component score and the components combine into a grade from A to E. (0.003 USDC on Base)
• POST /v1/dependency-graph — Returns the resolved dependency graph of one package version across seven ecosystems: every node with its ecosystem, name, resolved version, whether it is bundled, and its depth from the root. Depth is computed as the shortest path from the root by breadth-first search — a depth-first walk loops forever on a cyclic graph and recursion overflows the stack on large trees, so neither is used. (0.005 USDC on Base)
• POST /v1/typosquat-radar — Generates the typical misspellings of a package name and looks up every one of them in the registry. Generation rather than search is deliberate: most of the seven ecosystems have no search API, and the ones that do rank by popularity instead of similarity, so a fresh squat with no downloads never appears. (0.006 USDC on Base)
• POST /v1/lifecycle-check — Answers the question an agent actually has about a product cycle: for the version in use, is support over, how many days remain, and where should it move. Given a product identifier from endoflife.date and optionally a version, it locates the matching release line and returns the release date, the end of active support, the end of life, the end of extended security support where one exists, whether the line is an LTS line, the latest patch release within that line and the number of days to each… (0.003 USDC on Base)
• POST /v1/dependency-bloat — Scores how much a package costs to depend on, using the resolved graph rather than a guess. Four measurements: the number of transitive nodes, the maximum depth, how many packages appear at more than one version, and the fan-out of the root. From those comes a grade from A to E with every threshold returned, so the judgement can be recomputed with different weights. (0.005 USDC on Base)
• POST /v1/upgrade-path — Turns "we are on 2.4.1 and want to be current" into an ordered list of stops. The rule it enforces is that no major version is skipped: going from 2 to 5 means stopping at the last release of 3 and the last release of 4, because that is where the migration notes live and where the warnings about the next major are published. (0.004 USDC on Base)
• POST /v1/maintainer-pulse — Answers whether the project behind a package is still alive, from two sources with different roles. deps.dev supplies stars, forks, open issue count, the declared licence and the OpenSSF scorecard without any rate limit or account. GitHub supplies the last push and recent commit activity, but only sixty requests per hour per IP without authentication, so it is treated as optional: when it is unavailable the response still comes back, the affected fields are named as unavailable, and the… (0.005 USDC on Base)
• POST /v1/deprecation-monitor — A monitor with memory. The first call stores a snapshot of the packages you name and returns the baseline, explicitly marked as such rather than reporting everything as new — a monitor that cries wolf on day one is not read on day two. Every later call with the returned snapshot token compares the current registry state against what was stored and reports the differences: packages whose newest version became deprecated, individual versions that gained a deprecation notice, and, equally… (0.004 USDC on Base)
• POST /v1/runtime-compat — Normalises what a package version declares about where it can run. For npm that is the engines, os and cpu fields plus the declared package type and whether native build scripts are present; for PyPI it is requires_python together with the operating system, implementation and Python version classifiers. (0.004 USDC on Base)