API - Repology

Terms of use

Bulk requests to this API are discouraged, consider requesting a bulk export. Bulk clients must identify themselves with a custom user-agent, referring to a description of the client and a way to report misbehavior (such as GitHub repository with an issue tracker). Bulk clients must not do more than one request per second. Miscomplying clients will be blocked.

Introduction

Note that API stability is currently not guaranteed - it may change at any moment.

API always returns a list of packages. Package is a dictionary of the following format:

{
    "repo": "freebsd",
    "srcname": "www/firefox",
    "binname": "firefox",
    "visiblename": "www/firefox",
    "version": "50.1.0",
    "origversion": "50.1.0_4,1",
    "status": "newest",
    "summary": "Widely used web browser",
    "categories": ["www"],
    "licenses": ["GPLv2+"],
    "maintainers": ["gecko@FreeBSD.org"]
}

Fields are:

repo: name of repository for this package
subrepo: name of subrepository (if applicable; for example, main or contrib or non-free for Debian)
srcname, binname: package name(s) as used in repository - source package name and/or binary package name, whichever is applicable (all fields are optional)
visiblename: package name as shown to the user by Repology
version: package version (sanitized, as shown by Repology)
origversion: package version as in repository
status: package status, one of newest, devel, unique, outdated, legacy, rolling, noscheme, incorrect, untrusted, ignored
summary: one-line description of the package
categories: list of package categories
licenses: list of package licenses
maintainers: list of package maintainers

Mandatory fields are repo and version, all other fields are optional.

Project is a group of related packages from different repositories (though it may contain multiple packages from the same repository). Project has its own name which is derived from package names. In most cases it's the same, but sometimes different package names are transformed into a single project name to coalesce differently named packages from different repositories.

API allows to request packages for a single project or for a range of projects.

Single project

Get list of packages for specific project (here, firefox):

/api/v1/project/firefox

Multiple projects

The following requests return data for multiple projects in form of project name → list of packages dictionary. API returns no more than 200 projects per request. You may specify a start or an end of project names range to request.

Get first 200 projects:

/api/v1/projects/

Get first 200 projects starting with firefox (inclusive):

/api/v1/projects/firefox/

Get last 200 projects up to firefox (inclusive):

/api/v1/projects/..firefox/

You may iterate through all projects by using the last project name in the next request

/api/v1/projects/  # returns '010editor' ... 'aaut'
/api/v1/projects/aaut/  # returns 'aaut' ... 'acf-snort'
/api/v1/projects/acf-snort/  # returns 'acf-snort' ... 'adinatha-fonts'
# ...

Filtered projects

API supports all the filters available on the website, so you can just play with filters in the website and then replace /projects/ URL prefix with /api/v1/projects/ to get API output.

Supported filters are:

search: project name substring to look for
maintainer: return projects maintainer by specified person
category: return projects with specified category
inrepo: return projects present in specified repository
notinrepo: return projects absent in specified repository
repos: return projects present in specified number of repositories (exact values and open/closed ranges are allowed, e.g. 1, 5-, -5, 2-7
families: return projects present in specified number of repository families (for instance, use 1 to get unique projects)
repos_newest: return projects which are up to date in specified number of repositories
families_newest: return projects which are up to date in specified number of repository families
newest: return newest projects only
outdated: return outdated projects only
problematic: return problematic projects only

Example: get unique outdated projects not present in FreeBSD maintainer by foo@bar.com

/api/v1/projects/?notinrepo=freebsd&maintainer=foo@bar.com&families=1&outdated=1

Problems

Get problems for specific repository or maintainer:

/api/v1/repository/freebsd/problems
/api/v1/maintainer/ports@freebsd.org/problems-for-repo/freebsd

Output is an array of entries of the following format:

{
    "type": "homepage_dead",
    "data": {
        "url": "http://artax.karlin.mff.cuni.cz/~brain/0verkill/",
        "code": 500
    },
    ...
    "repo": "freebsd",
    "srcname": "games/0verkill",
    "binname": "0verkill",
    "rawversion": "0.16_2",
    "maintainers": [
        "mich@freebsd.org"
    ],
    "effname": "0verkill",
    "version": "0.16",
    ...
}

Fields are:

type: problem type string constant
data: additional details on the problem in the form of JSON dictionary
*: unspecified set of internal fields for package which generated this problem. You may use some of them to identify the package, but they may change in the future