All our APIs

For F-Droid to be trusted, we need to be transparent. Making it easy for people to pay attention to all the processes and systems we use helps us stay secure. These are the APIs with key information about the publishing process.

Active packages

There is a per-app API accessible via, which can be used to query information about the applications in the main repository. The JSON API currently lists the published and suggested versions. Archived applications and packages are not available in this API.

Example request:


Example response:

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
  "packageName": "org.fdroid.fdroid",
  "suggestedVersionCode": 1009000,
  "packages": [
      "versionName": "1.10-alpha0",
      "versionCode": 1010000
      "versionName": "1.9",
      "versionCode": 1009000

This API is already used by project to provide F-Droid badges, like this.

The repo index

F-Droid is built around a signed index of all the apps and packages that are available. This is a JSON file, though more of an index than an API since all the information is distributed via a single file.

As of index-v2, there is support for files that only contain the changes, known as “diff” files. There is also a separate entry point, which is signed by a JAR and a GPG signature and lists the available index and diff files.

The v1 repo index formats come in the form of a signed JAR file that contains index-v1.json. The best method is to verify the JAR signature, then extract index-v1.json if it validates. The fdroidserver Python library provides fdroidserver.download_repo_index() to make this easy to do.

There are also GPG signatures for verifying the JSON files:

App Search API

We’ve got a basic web-api for performing a full-text searches on the repository.

App build metadata

Every app in has a corresponding build metadata file in fdroiddata. In order to encourage more creative reuse, we keep our data in standard formats in easy to find places. The whole app collection is in YAML format. The file can be directly accessed by Application ID using the GitLab Raw URL<ApplicationID>.yml (e.g. The repo index and the GitLab Repository Files API can be used to query which Application IDs are available. These files are also available via the mirror on GitHub, e.g. build server status

The four main steps of the build cycle are: checkupdates, build, update, and deploy. There is a JSON file for each one of those with status information. It is posted once that step completes running. The step that is currently running is posted to running.

Two examples of how these JSON APIs can be used are the F-Droid Monitor website and the F-Droid Build Status app.

Mirror and repo monitoring

mirror-monitor and repo-monitor are automated jobs that check various stats about mirrors and third party repos respectively. They each provide a single, large JSON log of all the times the checks where run:

Reproducible builds is a rebuilder that rebuilds the official releases from, then checks to see if they were reproducibly built. There is an entry point for each package based on the package name:

Then there is a JSON file per APK that has been checked, where the filename follows the pattern <ApplicationId>_<VersionCode>.apk.json, for example:

There is also a listing of all the successfully verified APKs:

Binary transparency logs

Binary transparency is the idea that all released packages should be logged as they are published. This provides a way to check if a given binary was produced by the publisher, or came from somewhere else, e.g. as an exploit. fdroidserver has built in tools for managing a binary transparency log of the index files as part of the release process. This has been enabled on

Since Gradle and the Google Android Tools team does not publish one, F-Droid has done it. The basic API is a JSON file with a listing of all URLs known to have be published. Each URL then contains a list of SHA-256 checksums that the log process has seen. There are also other files tracked, based on what the publisher provides.


issuebot runs on app merge requests and requests for packaging (RFP) to provide information to reviewers about the app. Much of that information is also published in JSON format. Each report is made of data from modules that run on a specific app. There are two entry points:


Usage data is gathered from various F-Droid websites and published with no personally identifiable information (PII). It is published with one JSON file per-week, with a JSON index file per website. For example, here is a week of search metrics:

Though not really an API, the mirror does provide some metrics:

Git stats

Each git repo has lots of interesting metadata. The GitStats project generates nice charts from that data. This is not quite an API, but it is related since it is using public project data. Pre-generated pages for each of the central git repos are visible here: