Notecard firmware not sorted by reverse creation date

Troubleshooting
1

# Firmware API Returns Unsorted Results

## Summary

The `/v1/projects/{projectUID}/firmware` API endpoint returns firmware entries in an inconsistent, unsorted order. This makes it difficult to identify the latest firmware version without client-side sorting.

## Expected Behavior

Firmware results for host firmware are sorted by the `created` field in descending order (newest first), but this is not the case when firmwareType=notecard is passed as a query parameter.

## Actual Behavior

The API returns results in an unpredictable order that doesnā€™t correspond to creation date, version number, or any other obvious field.

## Test Results

I tested the API with various `target` filters and found inconsistent sorting across all cases:

### Example 1: `target=u5` (UNSORTED)

```

1. Version 6.2.5.16868 created=1724159649 (2024-08-20)

2. Version 9.3.1.17434 created=1760731940 (2025-10-17) ā† newest

3. Version 8.2.3.17326 created=1755007181 (2025-08-12)

```

### Example 2: `target=r5` (UNSORTED)

```

1. Version 6.2.5.16868 created=1724159647 (2024-08-20)

2. Version 9.3.1.17434 created=1760731950 (2025-10-17) ā† newest

3. Version 8.2.3.17326 created=1755007170 (2025-08-12)

```

### Example 3: `target=wl` (UNSORTED)

```

1. Version 6.2.5.16868 created=1724245223 (2024-08-21)

2. Version 9.3.1.17434 created=1760731936 (2025-10-17) ā† newest

3. Version 8.2.3.17326 created=1755101924 (2025-08-13)

```

### Example 4: `target=s3` (Correctly sorted - newest first)

```

1. Version 9.3.1.17434 created=1760731945 (2025-10-17) ā† newest

2. Version 8.2.3.17326 created=1755007192 (2025-08-12)

```

## Impact

This inconsistent sorting creates several issues:

1. **OTA Update Logic Complexity**: Applications implementing OTA firmware updates must sort results client-side to identify the latest firmware

2. **Cellular Data Waste**: Without server-side sorting, devices must download more results than necessary to ensure they get the latest firmware

3. **User Confusion**: When viewing firmware lists through the API, users canā€™t easily see which firmware is newest

4. **Inconsistent API Behavior**: The `s3` target appears sorted while others are not, suggesting this may be a bug rather than intentional design

## Reproduction

```bash

curl -H ā€œAuthorization: Bearer YOUR_TOKENā€ \

ā€œhttps://api.notefile.net/v1/projects/YOUR_PROJECT/firmware?firmwareType=notecard&target=u5ā€

```

Compare the `created` timestamps in the response - they will not be in descending order.

## Workaround

For now, applications must sort results client-side:

```javascript

// Example: Sort firmware by created timestamp descending

const firmware = apiResponse.sort((a, b) =>

parseInt(b.created) - parseInt(a.created)

);

const latestFirmware = firmware[0];

```

For Notehub routes using JSONata transforms:

```jsonata

$ ^(>created) /* Sort by created descending */

```

## Request

Could the firmware API be updated to return results sorted by `created` timestamp in descending order (newest first) by default? This would:

1. Match user expectations for time-series data

2. Reduce complexity in OTA update implementations

3. Minimize cellular data usage for constrained devices

4. Provide consistent behavior across all firmware types and targets

Alternatively, if thereā€™s a query parameter for sorting (like `sortBy=created&sortOrder=desc`), that would also work - though I didnā€™t see this documented in the API reference.

## Environment

- API Endpoint: `https://api.notefile.net/v1/projects/{projectUID}/firmware\`

- Tested with: `firmwareType=notecard` and various `target` filters (r5, wl, s3, u5)

- Tested on: 2025-11-23

Thank you for looking into this!

3

Hey @devElert,

Thanks for the thorough writeup! I verified the inconsistencies and Iā€™ll get this logged as an issue on our end.

Thanks,

TJ

1 Like
4

We recently added a sortby field to the API which allows you to sort by:
created (date), name, version, length

4 Likes