For organizers who like their data handy
QR code data that AI agents can read
Every sign-up and feedback card can turn on one switch and gain a second personality: a small, documented data endpoint. The address doubles as its own instruction manual — paste it into ChatGPT, Claude or any tool-calling agent, and it reads the fields, fetches the records and builds the dashboard or recap you would otherwise export by hand.
Make a card whose data travels →How the switch works
→Off by default, always your call. On the card's data page, the open-interface toggle flips one bit. Nothing is public until you flip it, and one flip back closes it.
→Self-documenting address. The endpoint is /c/{shortId}/q; the same address with ?help returns a plain-language Markdown manual — the fields, the paging, the rules — written for a reader that happens to be a model.
→No keys, no accounts, nothing to wire up. An agent that can fetch a URL can read it: read the manual, request pages of records, and lay them out — same data your CSV exports, in machine-readable columns.
→Channel context rides along. Submissions that came in through tracked links keep their campaign fields (_utm_source and friends) as first-class columns — the agent can tell you which flyer actually filled the room.
Try it in three steps
1 · Flip the switch
Open your card's data page, turn on the open interface, copy the documentation address it shows you.
2 · Hand it to the AI
Paste the address into ChatGPT or Claude with a sentence of intent: "read this card's data and build me a page that shows arrivals by hour."
3 · Ask for the recap
After the session, the same link lets an agent total the counts, quote the wall, and draft the follow-up — before you have opened a spreadsheet.
The live projector screen runs on the same aggregate — see the trainer live screen and the message wall; the theory of the card behind it is in How Cards Work.
The honest trade-off: open means open
Turned on, the endpoint serves the card's submitted rows to anyone holding the address, anonymously — that is the whole idea, and the whole cost. It is right for public-looking collections (an event's arrival count, a feedback wall you already showed the room); it is wrong for a signup list holding attendees' emails and phone numbers.
→The switch never touches what the projector shows: sign-up cards put counts, not contact details, on any screen — that privacy line is independent of this setting and is never relaxed by it.
→Reads are rate-limited and page-capped; the endpoint is documentation-first by design (the help page is the agreement). Treat the address like a published thing, because when it is on, it is.
→Default off. Flip it for the cards whose data was always meant to be public, and let the CSV stay the private path for the rest.
Questions agents-and-humans both ask
Which cards support it?
Sign-up, check-in and feedback cards (the ones with records). Link cards have no data of their own, so there is nothing to open.
Does every AI assistant support this?
Any tool that can browse or fetch a URL and follow written instructions — which covers the major chat assistants with web access and most agent frameworks. The manual at the help address exists precisely so no integration step is needed.
Can the site itself be read by AI crawlers?
Yes — the documentation files (llms.txt and its full sibling) are intentionally open to AI crawlers, so models can find what a QRCard is before anyone asks them mid-planning.
What happens when I switch it back off?
The endpoint stops answering immediately — the next fetch gets nothing, same as a card that never had it. Your data page and CSV export are unaffected either way.
Make the next event's data AI-legible
Create the card, run the room, then let a model do the recap — the switch waits for you on the data page.