Your app already knows the number. There’s an endpoint for it, /api/stats or /admin/metrics, and you curl it whenever you want to know how the day is going.
That works. It’s also a terminal command you run twenty times a week to read one figure.
What the board shows
Paste the address and the board reads the answer and offers what’s worth showing. Counts and totals come first, one tap each. A list of dates with numbers becomes a line over time. Any other list becomes a list, and your agent can turn rows into a table. Ids, sizes and dates are left out of the picks, because nobody wants a widget that says 1729036800.
None of those right? Open the answer and point at the value you want, however deep it sits.
Before anything is added, the form shows what the widget will say. The number, the first rows, the line. What you see there is what lands on the board.
For data with more shape than a number, like a forecast with a list for every day, the whole answer can go to a custom widget your agent writes. Custom widgets run sealed off, with no network access.
Where the numbers come from
From the API itself, read on the board’s own server while the board is open, on the schedule you pick. A number’s line grows with every read. If a read fails, the widget keeps the last good value and says what went wrong and when.
If the API wants a key, the board asks for it. Paste it and say how it goes out, as a bearer token or under a header of its own like X-API-Key. The key is sealed on the board’s server, never shown again, and sent only to the site you typed it for.
Paste the address of a service the board already knows, like Stripe, and it sends you to that service’s own form instead, where one saved key covers every board.
Your agent can do all of this as well. It tries the address first, reads the answer, picks the value, and the source keeps reading by itself. If what you need is a number no API gives you, n8n, a cron job or a GitHub Action can push it to the board instead.