Although originally intended to be written in NodeJS and PostgreSQL, the decision was made to implement the API in PHP and calling into a MySQL database, as this allows deployment on a standard web hosting plan, and avoids the additional cost and setup of virtual private servers. The API returns dynamically generated JSON and serves encrypted firmware binaries if necessary.

The MySQL database is structured using first normal form, with tables holding information pertaining to Puft device types, Puft devices, firmware details, device firmware history, and valid download requests.

Simplified, the steps taken to check for and download an update binary are:

1. Perform a HTTP GET on the update URL to check for available updates. 
2. Perform a HTTP GET on the download URL to download the available update returned in step 2.
3. Perform a HTTP POST on the complete URL to provide documentation of a successful update.

In order to perform the above steps the Puft device details must first be entered into the database at the time of production in order to successfully validate the authenticity of the device contacting the server.

Requesting an update check by performing a HTTP GET on the update URL first queries the database to ensure device validity. If the device requesting the check is invalid, then a failure reason is returned in the JSON. Given the device is valid, the current firmware is then checked the latest available firmware binary for the given update channel the device is subscribed to ie. beta or stable. If an available update is found then a time-constrained download token valid only for the identified firmware is generated and returned.

The firmware update binary is then downloaded from a publicly inaccessible directory via a HTTP GET request using the generated token, given the provided token is within the valid download window and the device is determined to be valid. The Puft device then undertakes a streamed OTA update process using the returned firmware.

Once the OTA update process has finished, the device performs a HTTP PUT request in order to update the device’s firmware history. Although this is not information used during the main check, download, and update process, it is useful information for customer support requests.

Overall, the combination of: pre-determined valid Puft device’s checked at each point of contact with the server, time-constrained download tokens, and encrypted firmware binaries stored outside of publicly accessible addresses, provides a secure and reliable update process with the flexibility of including test users into potentially unstable release streams.