AI visibility in Airtable

An Airtable base is a fine system of record for AI visibility: one table of queries you care about, one table of runs, one record per engine answer with its citations — filterable, groupable, shareable with the team. What Airtable is not is a place to hold a slow HTTP request: automation scripts run under a tight execution cap, and a live multi-surface fetch can take up to 180 seconds. So the honest wiring puts the slow part on AgentGEO's side. A server-side schedule scrapes the engines on cadence; an Airtable automation polls the fast read endpoint and files whatever's new. No AgentGEO app in the marketplace, no extension to install — one scripting step and a REST contract.

The result: your base fills itself. Every run lands as records carrying the engine, the verbatim answer, each cited source with its URL and position, and the run ID that makes the row auditable back to the exact provider record.

Step 1: A schedule on the AgentGEO side

Create it once, in the console's Schedules page or with one call — POST /v1/schedules with your query, surfaces and a daily or weekly cadence. From then on the engine answers accumulate in your run history without anything holding a connection open.

Step 2: An automation that files new runs

In Airtable, add an automation — trigger "At scheduled time", action "Run a script". The script polls run summaries, pulls full answers for anything it hasn't filed, and creates records:

const KEY = "ag_live_..."; // store as an input variable, not in the script
const table = base.getTable("AI answers");

const listResp = await fetch("https://api.agentgeo.org/v1/runs?limit=10", {
  headers: { Authorization: `Bearer ${KEY}` },
});
const { runs } = await listResp.json();

// Which runs are already filed? (Run ID column keeps the script idempotent.)
const existing = new Set(
  (await table.selectRecordsAsync({ fields: ["Run ID"] })).records.map(
    (r) => r.getCellValueAsString("Run ID"),
  ),
);

for (const summary of runs) {
  if (summary.status !== "completed" || existing.has(summary.id)) continue;
  const runResp = await fetch(
    `https://api.agentgeo.org/v1/runs/${summary.id}`,
    { headers: { Authorization: `Bearer ${KEY}` } },
  );
  const run = await runResp.json();
  for (const a of run.answers) {
    if (a.status !== "delivered") continue;
    await table.createRecordAsync({
      "Run ID": run.id,
      "Query": run.query,
      "Engine": a.surfaceKey,
      "Answer": a.answerText,
      "Cited URLs": a.sources.map((s) => s.url).join("\n"),
      "Fetched at": a.fetchedAt,
    });
  }
}

Both calls are fast reads — they return in moments no matter how slow the underlying scrape was, which is what keeps the script comfortably inside Airtable's execution cap. Reads cost no credits; only delivered records on the schedule side do (one credit each, failed fetches free).

Views worth building on top

• "Are we cited?" view. Filter records where Cited URLs contains your domain; group by engine. The empty groups are the work list.
• Competitor grid. A formula field per competitor domain, checked against Cited URLs — a share-of-voice matrix that updates itself. What to compute from it: the share-of-voice use case.
• Answer-change log. Group by query, sort by Fetched at, and skim how the answer text drifts week over week — drift is often the first sign an engine re-sourced its answer.
• Client-facing share. Airtable's shared views give agencies a zero-build client portal over the same records that feed white-label reports.

More integrations

Same poll-and-file pattern, different homes: Google Sheets via Apps Script, Zapier step by step, or row-per-company enrichment in Clay. See all integrations.