Read your records back
Create, Update, and Delete all describe what a submission does to a Sheet. Fetch is the other direction: your own application asks Webtzm for the rows a workflow created and receives them as JSON.
A fetched record carries the same record ID an Update or Delete workflow needs, so the loop closes. Fetch reads only Sheets that Webtzm created for the workflow. A Sheet supplied by hand cannot be read back, and the panel says so rather than offering a control that would fail later.
- The panel has no apply button because it does not need one: every choice on it is saved as you make it, and the line at the top of the panel reports each save.
- No column is readable until it is selected. Removing one takes effect immediately.
- Keep Record id on when the application will later update or delete the row.
- A key is shown once and never again. Webtzm stores only a fingerprint of it.
- Fetch never writes. Rows change only through a submission.
How current the answer must be
| Setting | Reused for | Choose it when |
|---|---|---|
| Live | Not at all | A dashboard must show a new row the moment it arrives |
| Standard | One minute | Almost every application |
| Economy | Five minutes | High-traffic pages, where cost matters more than the last minute |
The Sheet is always the source, so a row edited by hand appears in every setting. Reading more often uses more of the workspace’s Google capacity.
Making a request
GET /fetch/YOUR_FORM_ID?limit=50
Authorization: Bearer YOUR_SERVER_KEYThe panel writes the whole request out for you under “What your app sends, and what comes back”, in the form the kind of key you picked actually takes, with a reply built from the columns and the freshness you chose. Copy it, put your own key in place of the placeholder, and it runs as it stands.
Retention shortens how long Webtzm keeps its own copy of what was submitted. It removes nothing from the Sheet, so Fetch keeps returning rows the workspace still holds in Google.