Your Form Data, Programmable: Query, Summary, and CSV Workflows

Storing submissions is only half a backend. The half that decides whether your data is useful is getting it back out—for a human to browse, for a script to process, for a dashboard to chart, for an agent to reason over.

A FormLM endpoint gives you three exits, and picking the right one is most of the design. Here is the whole toolkit, with the loops and schedules that turn "collected data" into "working data."

The three exits

• The data UI — the inbox every published form ships with: browse submissions, inspect records, export CSV. Right for humans and one-off pulls.
• The query endpoint — GET /query?page=1&size=20 returns stored records as paginated JSON, up to 1,000 per page. Right for scripts and syncs.
• The summary endpoint — GET /summary answers aggregate questions directly: counts, distributions, and statistics over everything collected. Right for dashboards that don't need raw rows.

Same data, three shapes. A Monday-morning "how did the workshop go?" is a CSV open; a nightly sync into a spreadsheet archive is the query loop; an always-live results widget is a summary call and a radar chart.

Paging through everything, safely

The query endpoint paginates, so the correct pattern is a loop that stops on a short page—never a hard-coded "take page 5 and hope." Two lines of bash and jq pull the full history into a local file:

page=1; out=all.jsonl; : > $out
while :; do
  resp=$(curl -s "https://formlm.me/api/v3/share/<your-token>/query?page=$page&size=1000")
  echo $resp | jq -c '.records[]?' >> $out
  n=$(echo $resp | jq '.records | length')
  [$n -lt 1000 ] && break
  page=$((page+1))
done

The same loop in Python or a platform script is a few more lines and the same idea. Keep size=1000—the per-page ceiling—for bulk pulls, and shrink it for interactive dashboards so a slow record never blocks the view. If you only ever need counts and distributions, skip the loop entirely: /summary already did that arithmetic server-side.

Aggregates without the raw rows

Dashboards rarely need every submission—they need "342 responses this week, dimension averages 3.8 / 2.9 / 4.1, band distribution 12% / 41% / 47%." The summary endpoint is exactly that trade: one GET, no pagination, nothing to join. Point a low-refresh widget at it and the entire reporting layer costs you a fetch and a chart.

Schema drift is a feature—read defensively

Because unknown payload keys auto-create their own columns, the field set of a live endpoint grows as your page evolves. Old records simply have nothing for new keys; that is not corruption, it is history. Three habits keep pipelines calm:

• Treat missing keys as null — iterate the union of fields, not the first record's field set.
• Re-read the schema from the endpoint — ?help returns the current field list as Markdown; diff it in your sync script and alert yourself when a new column lands.
• Name keys deliberately — a typo'd key doesn't fail, it quietly creates a column; the ?help diff is your tripwire.

Scheduled exports to sheets and BI

For teams that live in spreadsheets, wrap the query loop in a nightly cron, write CSV or append rows to your sheet, and let the form stay boring infrastructure. There is a simpler tier for smaller needs—manual CSV export from the data UI—so you only automate when volume actually justifies it. And for BI tools that can hit an HTTP source, the query endpoint speaks their language directly: JSON with stable record IDs.

Feed the results back to an agent

The exit that surprises people: an agent can consume what the agent produced. Paste an endpoint's ?help into a conversation and the agent knows the schema; pipe in a /summary JSON and it can narrate this week of results; hand it the query loop output and it writes the report. Storage stops being the end of the form's life and becomes the start of an analysis loop—the same URL that collected the data is the one that explains it.