beehiivYour n8n workflows already know the numbers. How many people signed up today, what the store took, which leads came in. Then the run finishes, the numbers sit in an execution log, and you go looking for them somewhere else.
One more node puts them on a board you actually look at.
How a workflow sends data to the board
At the end of the workflow, add n8n’s HTTP Request node. Set the method to POST and the URL to your widget’s push address. Turn on Send Headers and add one named Authorization with the value Bearer and your key. Turn on Send Body, choose JSON, and send the number.
Under the hood it is the same request as this curl.
curl -X POST https://board.contextbolt.com/v1/push/signups \
-H "Authorization: Bearer YOUR_KEY" \
-H "Content-Type: application/json" \
-d '{"value": 42}'The last part of the address, signups here, names what you are sending. Connect shows you the full address for your widget when you make the key.
A few workflows worth starting with.
- Signups every hour: a Schedule Trigger, a step that counts today’s signups in your database, then the HTTP Request node. Each value becomes a point on the widget’s history, so the chart draws itself.
- Sales as they happen: a Stripe Trigger on each new charge, a step that adds up today’s total, then the push.
- The newest leads: send
itemsinstead ofvalue, a list of names with a detail each, and a list widget shows them.
What you can send
Send value for a number, points for a history, items for a list, rows for a table, or text for a short report. A push the board cannot read is refused, never stored as zero, and the reply says what went wrong.
Pushes land whether or not the board is open. Open it in the morning and the night’s runs are there.
The key itself can only send. It puts data on your board and does nothing else. It cannot read the board, change a widget or reach any of your connections. If one ever leaks, remove it in Connected and make another in a minute.