How to connect Google Forms to OpenClaw

The ClawHub skill teaches OpenClaw about Google Forms, but the calls run through the ClawLink plugin and your connected account. Make sure Google Forms is connected in the dashboard, then start a fresh chat so OpenClaw reloads the tool catalog. If OpenClaw runs as a persistent gateway, restart it so the new tools register.

Reconnect Google Forms from the dashboard, then start a fresh chat if the runtime still has the old tool catalog loaded.

Google Forms tool schemas load on demand the first time a tool runs and are cached after that, so this error usually clears on its own: wait a few seconds and retry the same request. If every Google Forms call keeps failing with it in a fresh chat, reconnect from the dashboard, and contact support if it still persists — that pattern points to a configuration problem on our side, not something you can fix by reconnecting again.

Two usual causes. The connected account may not have access to the specific workspace, inbox, store, or project in the request — check that first. If access looks right, the agent may have sent a placeholder value (like "YOUR_ID" or an example id from documentation) instead of a real one: ask it to run a list or search tool first, then retry the action with a real id from those results. Most failures at this stage are one of these two, not ClawLink bugs.

Search results answer this with three self-hosted fixes — add the Forms scope to your OAuth client, publish your consent screen out of testing, delete the stale token.json and re-authenticate. None of those apply here, because there is no OAuth client of yours, no consent screen you own, and no token file on your machine. The causes that do apply are simpler. First, access: the connected Google account must have edit access to that specific form, and opening it in a browser signed in as a different account proves nothing. Second, which account approved the connection, since personal and work accounts see entirely different forms. Third, a partial approval on the consent screen, which leaves a connection that reads but cannot write — reconnect from the dashboard and accept the full set. Fourth, a placeholder form id from an example, which Google rejects as a permission error rather than a not-found.

Ask the agent to diagnose it:

Tell me which Google account this connection is acting as, then run googleforms_get_form on the form id and quote the exact error. Do not retry after that.

Two causes worth separating. The first is access level: reading responses needs more than being able to view the form, so an account with view-only access can fetch the form structure and get nothing back for responses. The second is the form id itself — the id in a form's edit URL and the id in its public response link are not interchangeable, and using the wrong one produces an empty or failing read that looks like there are no submissions. Have the agent fetch the form with googleforms_get_form first and confirm it is looking at the form you mean before you conclude anything about the responses.

Ask the agent to diagnose it:

Run googleforms_get_form for the id I gave you and tell me the form's title and how many items it has. Then run googleforms_list_responses and tell me exactly what came back.

Watches expire, which is by design rather than a failure. googleforms_create_watch registers a notification with a limited lifetime, so a workflow that depends on it needs googleforms_renew_watch on a schedule or it goes quiet without any error appearing anywhere. Run googleforms_list_watches to see what is currently registered and when it lapses. If the workflow only needs to catch up rather than react instantly, reading responses periodically with googleforms_list_responses is simpler and has nothing to expire.

Try reconnecting Google Forms and complete the consent flow in the same browser session. Partial OAuth approvals or switching accounts mid-flow can leave the connection incomplete.

Yes. ClawLink is the fastest way to connect OpenClaw to Google Forms: link your Google Forms account once in the browser and OpenClaw can call the Google Forms API through 10 ready-made tools — no custom code or token handling.

Paste the setup prompt from this page into OpenClaw. It installs the ClawLink Google Forms skill from ClawHub, then you click Connect in the dashboard to authorize Google Forms. OpenClaw calls the tools from the next message — no config files or API keys to manage.

About two minutes. Sign in, click Connect next to Google Forms in the dashboard, authenticate, and OpenClaw can use it from the next chat message.

The alternative to ClawLink is usually manual OAuth app setup plus your own token handling, permission troubleshooting, and tool plumbing for OpenClaw. That is fine if you want to build and maintain the integration yourself. Most teams just want Google Forms working from chat.

No, and this is the difference from every walkthrough you will find. Those have you create a project, enable the Forms API, configure an OAuth consent screen, run a local auth flow, and end up with a token.json sitting next to your script that expires and has to be regenerated — which is why so much of the troubleshooting advice online is "delete token.json and re-authenticate". There is no token file here and no consent screen of yours to publish. You approve access on Google's screen and the credential stays on the ClawLink server.

Both. googleforms_create_form makes a new form and googleforms_batch_update_form changes its structure — adding questions, editing them, reordering, and updating settings. Reading is googleforms_list_responses for everything and googleforms_get_response for one submission. The practical note on creation is that a new form starts effectively empty, so building a real form is a create followed by a batch update that adds the items, rather than one call that does everything.

Through a watch. googleforms_create_watch registers a notification for new responses or schema changes, googleforms_list_watches shows what is registered, and googleforms_renew_watch keeps it alive — watches expire, so a watch created and forgotten stops firing after its window. This is the piece the spreadsheet-based approach replaces with polling a sheet, and it is more direct, but it does need renewing rather than being set once.

It depends on where the work is. If the job is reading submissions and doing something with them, the linked spreadsheet is a perfectly good surface and the Google Sheets integration handles it, which is what most published workflows do. Use the Forms API when the form itself is part of the work: generating forms from a template, changing questions in response to something, publishing or unpublishing, or reading responses with their question structure intact rather than flattened into columns. The structured read is the underrated part, because a spreadsheet row loses which question an answer belonged to.

The ClawHub skill teaches OpenClaw about Google Forms, but the calls run through the ClawLink plugin and your connected account. Make sure Google Forms is connected in the dashboard, then start a fresh chat so OpenClaw reloads the tool catalog. If OpenClaw runs as a persistent gateway, restart it so the new tools register.