Skip to content


This page describes using the QMK API. If you are an application developer you can use this API to compile firmware for any QMK Keyboard.


This service is an asynchronous API for compiling custom keymaps. You POST some JSON to the API, periodically check the status, and when your firmware has finished compiling you can download the resulting firmware and (if desired) source code for that firmware.

Example JSON Payload:

  "keyboard": "clueboard/66/rev2",
  "keymap": "my_awesome_keymap",
  "layout": "LAYOUT_all",
  "layers": [

As you can see the payload describes all aspects of a keyboard necessary to create and generate a firmware. Each layer is a single list of QMK keycodes the same length as the keyboard's LAYOUT macro. If a keyboard supports multiple LAYOUT macros you can specify which macro to use.

Submitting a Compile Job

To compile your keymap into a firmware simply POST your JSON to the /v1/compile endpoint. In the following example we've placed the JSON payload into a file named json_data.

$ curl -H "Content-Type: application/json" -X POST -d "$(< json_data)"
  "enqueued": true,
  "job_id": "ea1514b3-bdfc-4a7b-9b5c-08752684f7f6"

Checking The Status

After submitting your keymap you can check the status using a simple HTTP GET call:

$ curl
  "created_at": "Sat, 19 Aug 2017 21:39:12 GMT",
  "enqueued_at": "Sat, 19 Aug 2017 21:39:12 GMT",
  "id": "f5f9b992-73b4-479b-8236-df1deb37c163",
  "status": "running",
  "result": null

This shows us that the job has made it through the queue and is currently running. There are 5 possible statuses:

  • failed: Something about the compiling service has broken.
  • finished: The compilation is complete and you should check result to see the results.
  • queued: The keymap is waiting for a compilation server to become available.
  • running: The compilation is in progress and should be complete soon.
  • unknown: A serious error has occurred and you should file a bug.

Examining Finished Results

Once your compile job has finished you'll check the result key. The value of this key is a hash containing several key bits of information:

  • firmware_binary_url: A list of URLs for the flashable firmware
  • firmware_keymap_url: A list of URLs for the keymap.c
  • firmware_source_url: A list of URLs for the full firmware source code
  • output: The stdout and stderr for this compile job. Errors will be found here.


If you're writing a tool that leverages constants used within QMK, the API is used to publish "locked-in" versions of those constants in order to ensure that any third-party tooling has a canonical set of information to work with.

The list of available constants can be retrieved by accessing one of the following endpoints:

$ curl # For `master`
{"last_updated": "2022-11-26 00:00:00 GMT", "constants": {"keycodes": ["0.0.1"]}}

$ curl # For `develop`
{"last_updated": "2022-11-26 12:00:00 GMT", "constants": {"keycodes": ["0.0.1", "0.0.2"]}}


Versions exported by the master endpoint are locked-in. Any extra versions that exist on the develop endpoint which don't exist in master are subject to change.


Only keycodes are currently published, but over time all other "externally visible" IDs are expected to appear on these endpoints.

To retrieve the constants associated with a subsystem, the endpoint format is as follows:


Which, for the metadata endpoint above results in a request of:

$ curl
    "ranges": {
        "0x0000/0x00FF": {
            "define": "QK_BASIC"
        "0x0100/0x1EFF": {
            "define": "QK_MODS"
        "0x2000/0x1FFF": {
            "define": "QK_MOD_TAP"