Registering a client User-Agent for a third-party app using the SOTAwatch3 API (JA spots/alerts, read-only)

Hello SOTA MT and all,

I’m JK1TBL, an amateur radio operator in Japan. I’m developing a small

mobile web app called “Smart HAMLOG” that helps Japanese operators with

logging. As one feature, it shows current SOTA activity (spots and alerts)

for Japan.

I’d like to declare the User-Agent it uses and confirm that our access

pattern is acceptable, in line with your API usage guidance.

How the app uses the API (read-only):

- Endpoints: SOTAwatch3 only (api2.sota.org.uk) — /api/spots/{count}/all

and /api/alerts. We do NOT use the database API (api-db2).

- Scope: results are filtered to the Japan associations (JA, JA5, JA6, JA8)

for display only. No spotting, no posting, no writes of any kind.

- User-Agent: “Smart HAMLOG ” (e.g. “Smart HAMLOG 2026.31.65”),

which includes a version string so you can identify the client.

- Server-side relay + caching: all requests are made by a single

Cloudflare Worker that caches upstream responses (spots ~90 s,

alerts ~300 s). So regardless of how many app users are active at once,

upstream requests are at most roughly one per 90 s (spots) and one per

300 s (alerts). The load on your servers is small and bounded.

- My contact details are below so you can always reach me if anything

looks wrong or if you’d like us to change something.

Could you kindly let me know:

1. Whether I need to register this User-Agent anywhere, or whether a

descriptive User-Agent like the above is sufficient?

2. Whether the usage described (read-only, cached, JA-filtered) is

acceptable as-is, or if you would prefer any adjustments — for example

a lower polling frequency, a different endpoint, or specific attribution?

I want to be a good citizen of the SOTA ecosystem and to follow your

preferences. Thank you very much for maintaining SOTAwatch and the API,

and for all the work behind SOTA.

73,

Hiroshi Yasukawa de JK1TBL

2 Likes