How to connect Airtable to OpenClaw

The ClawHub skill teaches OpenClaw about Airtable, but the calls run through the ClawLink plugin and your connected account. Make sure Airtable 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 Airtable from the dashboard, then start a fresh chat if the runtime still has the old tool catalog loaded.

Airtable 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 Airtable 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.

The causes the search engines teach for this error are token-level: missing scopes on a PAT, missing base access in the Developer Hub, field-level rights. In a hosted connection the token-level causes do not exist, and the real checks are the account-level ones. The connected account must be a collaborator on the base in the request, with a role that permits the operation: a viewer can read records but cannot update them, and a base not shared with the account at all returns a permission error rather than a not-found. Second, the agent may have sent a placeholder or guessed id (like "YOUR_ID" or a sample base id from documentation) instead of a real one: ask it to run airtable_list_bases first and retry with the real base or record id from those results.

Ask the agent to diagnose it:

Run airtable_list_bases and airtable_get_base_schema for the base in question and show me the real ids. Quote the exact 403 text, then retry with a real id from that list.

Two different failures. If OpenClaw shows no Airtable tools at all, the connection or pairing is incomplete: confirm the skill was installed, that Airtable shows as connected in the dashboard, and start a fresh chat so the tool catalog reloads. If most tools work and a single name fails, that name is wrong rather than missing: the error lists the closest real tools, and clawlink_list_tools --integration airtable shows the exact catalog. There is also a first-call timing case unique to this setup: schemas load on demand, so the opening Airtable call in a fresh session can arrive before the catalog and needs one retry. What does not apply is the advice for this symptom that assumes a local MCP server installed with npm and declared in a client config, which is what the search results teach.

Ask the agent to diagnose it:

List the Airtable tools you actually have access to. If there are none, run clawlink_list_integrations and say so plainly. If there are, tell me which one lists bases and use that exact name.

Airtable records are addressed by record id, and the two failures here are the two causes. First, the agent used a name or a display value where an id was required, which either fails with a not-found or, worse, resolves to a different record. Second, the id came from a different base or table than the one being updated: ids are not unique across bases. The fix is to ground the call in the schema first: airtable_list_records on the specific table returns the ids that table actually holds, and airtable_get_base_schema confirms table and field names before a payload is built. A confirmation step before any update_multiple operation is the cheapest guard against a bulk change landing in the wrong rows.

Ask the agent to diagnose it:

Run airtable_get_base_schema for the base, then airtable_list_records for the table. Show me the record ids and confirm which rows you intend to update before you send the update.

Try reconnecting Airtable 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 Airtable: link your Airtable account once in the browser and OpenClaw can call the Airtable API through 23 ready-made tools — no custom code or token handling.

Paste the setup prompt from this page into OpenClaw. It installs the ClawLink Airtable skill from ClawHub, then you click Connect in the dashboard to authorize Airtable. 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 Airtable 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 Airtable working from chat.

No. The recipe most guides teach is: create a Personal Access Token with data.records:read/write and schema.bases:read, put it in .env, restart the agent, and keep it safe because anyone with it owns that much of your account. Here the authorization happens on Airtable's consent screen in the browser, the connection is stored server-side, and the token is never copied anywhere. The scopes exist either way, which is the honest way to say it: the hosted connection holds them for you, so you never see, manage, or accidentally leak a secret.

Yes, and that is the specific query this flow answers. The alternative shapes the engines describe are a PAT in an env file or a custom skill file with the token baked in; both mean a secret on your machine. Here the agent manages bases through a hosted OAuth connection: you approve once in the browser, OpenClaw calls the Airtable tools, and the credential exists only server-side. Bases you can see are bases the agent can reach, and revoking the connection from the dashboard removes its access immediately.

The AI Overview answers this query yes-if-scoped, and its named risks are prompt injection, excessive permissions, and bad data loops, with least-privilege and human-in-the-loop as the mitigations. The hosted setup removes the permission-management half of that: the grant is a single OAuth connection you can revoke in one click, and there is no token to over-scope or leak. The behavioral half is yours: start with reads, ask the agent to confirm before writes like updating records or deleting fields, and treat base contents as untrusted input so a malicious cell cannot talk the agent into doing something it was not asked to do.

The 23 tools cover the schema and record surface: bases and their schemas, tables and fields, records and bulk record operations, comments, and user info. The writes to be deliberate about are record updates and table or field changes, because those change data other people rely on, and schema changes (creating tables or fields) reshape the base itself. Reading the base schema first, with airtable_list_bases and airtable_get_base_schema, is the habit that keeps an agent from building a payload against the wrong field.

The ClawHub skill teaches OpenClaw about Airtable, but the calls run through the ClawLink plugin and your connected account. Make sure Airtable 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.