API - Repology

Terms of use

Bulk requests to this API are discouraged, consider using a database dump. 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",
    "binnames": ["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: source package name as used in repository, if applicable.
binname: binary package name as used in repository, if applicable.
binnames: binary package names for a source package, if applicable. Only returned by single project endpoint.
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%40bar.com&families=1&outdated=1

Problems

Get problems for specific repository or maintainer:

/api/v1/repository/freebsd/problems
/api/v1/maintainer/ports%40freebsd.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
    },
    "project_name": "0verkill",
    "version": "0.16",

    "binname": "0verkill",
    "srcname": "games/0verkill",
    "rawversion": "0.16_2"
}

Fields are:

type: problem type (string constant)
data: additional details on the problem (dict)
project_name: Repology project name
version: normalized version as used by Repology
srcname: repository (source) package name
binname: repository (binary) package name
rawversion: repository package version

This API returns limited number of problems and supports pagination by project name via ?start=<project_name> parameter.