MSYS2 APIpackages.msys2.org ↗
Access MSYS2 package search, repo listings, build queues, mirrors, and traffic stats via a structured API. 9 endpoints covering all major MSYS2 repositories.
What is the MSYS2 API?
This API exposes 9 endpoints covering the full MSYS2 package ecosystem, from searching packages by name to retrieving per-package dependency trees and file sizes. The get_package_detail endpoint returns version, build date, homepage, dependencies, package size, and installed size for any binary package across all MSYS2 repositories. Endpoints also cover build queue status, pending removals, outdated packages, mirror health, and traffic statistics.
curl -X GET 'https://api.parse.bot/scraper/6fe13aed-0ff7-4718-8322-a870fca218c5/search_packages?qtype=pkg&query=gcc' \ -H 'X-API-Key: $PARSE_API_KEY'
Typed, relational, agent-ready
A generated client with real types, enums, and the links between objects — the structure a flat JSON response can't carry. Autocompletes in your editor and reads cleanly to coding agents.
- Fully typed · autocompletes
- Objects link to objects
- Typed errors & pagination
Typed Python client. Set up the SDK in your uv project, then pull this API’s typed client:
uv add parse-sdk uv run parse init uv run parse add --marketplace packages-msys2-org-api
uv run parse add --marketplace pulls a pinned snapshot of this canonical API — it won’t change underneath you. To customize it, subscribe and swap to your own copy.
"""Walkthrough: MSYS2 Packages SDK — search, inspect, and monitor the package ecosystem."""
from parse_apis.msys2_packages_api import MSYS2, SearchType, Repository, PackageNotFound
client = MSYS2()
# Search for packages by base name — returns exact match + related results.
result = client.packages.search(query="python", qtype=SearchType.PKG)
print(f"Search '{result.query}': exact={result.exact.name if result.exact else None}, related={len(result.other)}")
# Drill into a specific binary package for full detail.
pkg = client.packages.get(package_name="mingw-w64-ucrt-x86_64-gcc")
print(f"Package: {pkg.name} v{pkg.version}, repo={pkg.repo}, size={pkg.package_size}")
# List packages in a repository via the sub-resource pattern.
repo = client.repo("ucrt64")
for p in repo.packages.list(limit=3):
print(f" {p.name} v{p.version}: {p.description}")
# Monitor outdated packages needing updates.
for outdated in client.outdatedpackages.list(limit=3):
print(f" {outdated.name}: {outdated.version_git} → {outdated.version_upstream}")
# Check mirror health — downloads and sync freshness.
for mirror in client.mirrors.list(limit=3):
print(f" {mirror.mirror}: {mirror.downloads_today} downloads, last sync {mirror.last_update}")
# Typed error handling: catch a missing package gracefully.
try:
client.packages.get(package_name="nonexistent-package-xyz")
except PackageNotFound as exc:
print(f"Expected error: {exc}")
print("exercised: packages.search / packages.get / repo.packages.list / outdatedpackages.list / mirrors.list")
Full-text search across the MSYS2 package repository by base or binary package name. Returns an exact match (if any) and a list of related results. The search is server-side; results are not paginated — a single request returns all matches.
| Param | Type | Description |
|---|---|---|
| qtype | string | Search type: 'pkg' for base package name, 'binpkg' for binary package name. |
| queryrequired | string | Search query string (e.g. 'gcc', 'python', 'boost') |
{
"type": "object",
"fields": {
"exact": "object or null — exact match package with name, version, descriptions, url, repos, arches, source_url, build_date, licenses, groups",
"other": "array of related package objects with same fields as exact",
"qtype": "string — the search type used",
"query": "string — the search query submitted"
},
"sample": {
"data": {
"exact": {
"url": "https://gcc.gnu.org/",
"name": "gcc",
"repos": [
"msys"
],
"arches": [
"x86_64"
],
"groups": [],
"version": "15.2.0-1",
"licenses": [
[
"spdx:GPL-3.0-or-later"
]
],
"realname": "gcc",
"build_date": 1756037706,
"source_url": "https://github.com/msys2/MSYS2-packages/tree/master/gcc",
"descriptions": "The GNU Compiler Collection"
},
"other": [
{
"url": "https://www.gnu.org/software/gcc/gcc.html",
"name": "mingw-w64-avr-gcc",
"repos": [
"clang64",
"mingw64",
"ucrt64"
],
"arches": [
"any"
],
"groups": [],
"version": "15.2.0-1",
"licenses": [
[
"spdx:GPL-3.0-or-later"
]
],
"realname": "avr-gcc",
"build_date": 1764446339,
"source_url": "https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-avr-gcc",
"descriptions": "GNU compiler collection for AVR"
}
],
"qtype": "pkg",
"query": "gcc"
},
"status": "success"
}
}About the MSYS2 API
Package Search and Detail
The search_packages endpoint accepts a query string and an optional qtype parameter to target either base package names (pkg) or binary package names (binpkg). Results are split into an exact match and an other array of related packages, so you can distinguish a precise hit from broader candidates. For full package metadata, get_package_detail takes a package_name such as mingw-w64-ucrt-x86_64-gcc and returns version, repo, homepage, build_date, description, base_package, dependencies (array of dependency names), package_size, and installed_size.
Repository and Queue Data
get_packages_by_repo accepts a repo parameter — one of ucrt64, clang64, clangarm64, mingw64, mingw32, or msys — and returns a list of package objects with name, version, description, and url. get_repos returns aggregate statistics for each repository including total packages count, package_size, and installed_size. The get_build_queue endpoint reflects packages currently queued for building, each with name, version, builds, repo_url, and version_repo fields; the array is empty when no builds are pending.
Maintenance and Infrastructure Signals
get_outdated_packages lists packages where the upstream version is newer than the packaged git version — useful for tracking ecosystem lag. get_removals surfaces packages pending deletion from the repositories. get_mirrors returns per-mirror downloads_today, last_update, and transferred_today, letting you assess mirror freshness and load. get_traffic_stats provides bandwidth data organized into four time-bucketed tables (hourly, daily, monthly, and top days), each containing Received, Sent, and time-period fields.
The MSYS2 API is a managed, monitored endpoint for packages.msys2.org — not a raw scraper you maintain. Every endpoint is automatically health-checked on a schedule, and when packages.msys2.org changes and a check fails, the API is automatically queued for repair and re-verified. It is built to keep working as the site underneath it changes.
This isn't an official packages.msys2.org API — it's an independent, maintained REST wrapper over public data. Where the source has no official API (or only a limited one), Parse gives you a stable contract over a source that never promised one, and keeps it current. Need a new endpoint or field? You can revise it yourself in plain English and the agent rebuilds it against the live site in minutes — contributing the change back to the shared API is free.
Will this API break when the source site changes?+
Is this an official API from the source site?+
Can I fix or extend this API myself if I need a new endpoint or field?+
What happens if I call an endpoint that has an issue?+
- Monitor the MSYS2 build queue to detect pending package updates before they land in a repository.
- Enumerate all packages in the ucrt64 or clang64 repo to audit toolchain coverage for a CI environment.
- Fetch dependency arrays from
get_package_detailto resolve transitive install requirements without running pacman. - Track
get_outdated_packagesto identify which MSYS2 packages lag behind upstream releases. - Check
get_mirrorsforlast_updateandtransferred_todayto select the most current mirror for automated downloads. - Compare
package_sizevsinstalled_sizefields across repos to estimate disk requirements for a deployment. - Watch
get_removalsto detect packages being dropped so dependent tooling can be updated proactively.
| Tier | Price | Credits/month | Rate limit |
|---|---|---|---|
| Free | $0/mo | 100 | 5 req/min |
| Hobby | $30/mo | 1,000 | 20 req/min |
| Developer | $100/mo | 5,000 | 100 req/min |
One credit = one API call regardless of which marketplace API you call. Exceeding the rate limit returns a 429 response. Authenticate with the X-API-Key header.
Does MSYS2 provide an official developer API for package data?+
What does `get_package_detail` return and how specific does the package name need to be?+
mingw-w64-ucrt-x86_64-gcc or mingw-w64-clang-x86_64-python. It returns name, repo, version, homepage, build_date, description, base_package, a dependencies array, package_size, and installed_size. Using a partial or base package name will not return results; you need the exact binary package identifier including the architecture prefix.Does the API expose the actual file list or changelog for a package?+
get_package_detail response covers metadata fields including dependencies and sizes but does not include a per-file manifest or version changelog. You can fork this API on Parse and revise it to add an endpoint that returns file list data if that is available on the source.Can I filter `get_packages_by_repo` to a specific package name prefix or architecture?+
repo parameter (e.g. ucrt64, msys) and returns all packages in that repository. Filtering by name prefix or architecture is not currently supported at the endpoint level. You can fork the API on Parse and revise it to add server-side filtering logic over the returned data.How current is the build queue and removal data?+
get_build_queue and get_removals reflect the state of the queue at the time the request is made. When no builds are pending or no removals are queued, the respective data arrays are returned empty. There is no historical queue data or timestamp indicating when the queue was last modified exposed in the current response schema.