appstore-api.repebble.com returns a links.share of the form https://apps.rebble.io/application/{id} for every application, including ones created on the new store. apps.rebble.io is the older Rebble store and its API does not have those applications, so a shared link cannot resolve to the app it names.
Measured today against two identifiers:
$ curl -s https://appstore-api.repebble.com/api/v1/apps/id/1b25cef73e2b471686672d07 \
| jq '.data[0] | {created_at, share: .links.share}'
{
"created_at": "2026-08-29T16:45:52.926",
"share": "https://apps.rebble.io/application/1b25cef73e2b471686672d07"
}
$ curl -s https://appstore-api.rebble.io/api/v1/apps/id/1b25cef73e2b471686672d07 | jq '.data | length'
0 # created on the new store: the old store has no such app
$ curl -s https://appstore-api.rebble.io/api/v1/apps/id/52cc44e045ffdd31dd000180 | jq '.data | length'
1 # a 2014-era app: present on both
apps.rebble.io answers 200 for any path with the same client-rendered shell it serves at / (about 666 KB, <title>Rebble Appstore</title>), so the failure is not visible from the status code.
The new store serves the page server-rendered at the bare identifier:
$ curl -sL https://apps.repebble.com/1b25cef73e2b471686672d07 | grep -o '<title>[^<]*'
<title>Watch Tools - Pebble Appstore
https://apps.repebble.com/en_US/application/{id} redirects to that form, so the bare identifier looks canonical.
This reads like a field missed during the migration rather than a deliberate choice: in the same links object, add_heart and remove_heart already point at appstore-api.repebble.com, while share and add_flag/remove_flag still point at appstore-api.rebble.io.
add_heart: https://appstore-api.repebble.com/api/v1/apps/id/{id}/heart
remove_heart: https://appstore-api.repebble.com/api/v1/apps/id/{id}/heart
add_flag: https://appstore-api.rebble.io/api/v0/applications/{id}/add_flag
remove_flag: https://appstore-api.rebble.io/api/v0/applications/{id}/remove_flag
share: https://apps.rebble.io/application/{id}
Filing here because there is no public repository for the store API. As far as I can tell this app is unaffected — links appears in PebbleWebServices.kt only inside a doc comment, with no @Serializable type decoding it — which is probably why it has gone unnoticed. It does affect anything that takes the API at its word.
appstore-api.repebble.comreturns alinks.shareof the formhttps://apps.rebble.io/application/{id}for every application, including ones created on the new store.apps.rebble.iois the older Rebble store and its API does not have those applications, so a shared link cannot resolve to the app it names.Measured today against two identifiers:
apps.rebble.ioanswers 200 for any path with the same client-rendered shell it serves at/(about 666 KB,<title>Rebble Appstore</title>), so the failure is not visible from the status code.The new store serves the page server-rendered at the bare identifier:
https://apps.repebble.com/en_US/application/{id}redirects to that form, so the bare identifier looks canonical.This reads like a field missed during the migration rather than a deliberate choice: in the same
linksobject,add_heartandremove_heartalready point atappstore-api.repebble.com, whileshareandadd_flag/remove_flagstill point atappstore-api.rebble.io.Filing here because there is no public repository for the store API. As far as I can tell this app is unaffected —
linksappears inPebbleWebServices.ktonly inside a doc comment, with no@Serializabletype decoding it — which is probably why it has gone unnoticed. It does affect anything that takes the API at its word.