← back to blog

how to track cloud phone activity in Airtable

May 07, 2026

how to track cloud phone activity in Airtable

a cloud phone Airtable tracking setup gives ops teams a structured, sortable, formula-powered home for everything happening across the fleet. unlike Notion (which is great for documentation) or a custom dashboard (which is great for visualization), Airtable sits in the middle: relational, queryable, and easy enough for non-engineers to extend.

this guide walks through wiring cloudf.one events into Airtable with three real production patterns.

what cloudf.one and Airtable bring together

cloudf.one’s events that fit Airtable tracking:

Airtable’s matching capabilities:

the result is an event log that doubles as a fleet management system. ops can drill into individual devices, sessions, and customer relationships from one place.

for the broader case why integration matters for cloud phone ops, see cloud phone CI/CD integration.

step 1: create the Airtable base

create a new base called Cloud Phone Operations. add three tables:

table: Devices

field type
Device ID Single line text (primary)
Model Single line text
Region Single select (SG, ID, VN, TH, PH)
Status Single select (online, offline, locked, maintenance)
Last Seen Date with time
Owner Linked record (-> Customers)
Total Sessions Count (rollup from Sessions)
Uptime % (30d) Formula

table: Sessions

field type
Session ID Single line text (primary)
Device Linked record (-> Devices)
User Email
Locked At Date with time
Unlocked At Date with time
Duration (min) Formula: DATETIME_DIFF({Unlocked At}, {Locked At}, ‘minutes’)
Status Single select (active, completed, expired)

table: Events

field type
Event Name Single line text (primary)
Type Single select (device.locked, device.unlocked, etc.)
Timestamp Date with time
Device Linked record (-> Devices)
Session Linked record (-> Sessions)
Status Single select (success, failed)
Error Details Long text

three linked tables, clean data model.

step 2: get an Airtable API token

go to https://airtable.com/create/tokens and create a personal access token with scopes: data.records:read, data.records:write, schema.bases:read.

scope it to the Cloud Phone Operations base. note the token value (pat_xxx) and the base ID (in the URL: app_xxx).

step 3: build the event-to-Airtable bridge

a serverless function receives cloudf.one webhooks and creates Airtable records. example in JavaScript:

export default {
  async fetch(request, env) {
    const event = await request.json();

    const eventRecord = {
      fields: {
        "Event Name": `${event.event} - ${event.device.model}`,
        Type: event.event,
        Timestamp: event.timestamp,
        Status: event.event.includes('failed') ? 'failed' : 'success',
        "Error Details": event.error?.message || ''
      }
    };

    // look up or create the Device record
    const device = await upsertDevice(env, event.device);
    eventRecord.fields.Device = [device.id];

    // if this is a session event, look up or create the Session
    if (event.session) {
      const session = await upsertSession(env, event.session, device.id);
      eventRecord.fields.Session = [session.id];
    }

    await fetch(`https://api.airtable.com/v0/${env.AIRTABLE_BASE_ID}/Events`, {
      method: 'POST',
      headers: {
        'Authorization': `Bearer ${env.AIRTABLE_TOKEN}`,
        'Content-Type': 'application/json'
      },
      body: JSON.stringify({records: [eventRecord]})
    });

    return new Response('OK');
  }
};

async function upsertDevice(env, deviceData) {
  // check if device exists, create if not, return record reference
  const search = await fetch(
    `https://api.airtable.com/v0/${env.AIRTABLE_BASE_ID}/Devices?filterByFormula={Device ID}="${deviceData.id}"`,
    {headers: {Authorization: `Bearer ${env.AIRTABLE_TOKEN}`}}
  );
  const result = await search.json();
  if (result.records.length > 0) return result.records[0];

  const create = await fetch(
    `https://api.airtable.com/v0/${env.AIRTABLE_BASE_ID}/Devices`,
    {
      method: 'POST',
      headers: {Authorization: `Bearer ${env.AIRTABLE_TOKEN}`, 'Content-Type': 'application/json'},
      body: JSON.stringify({
        records: [{fields: {
          "Device ID": deviceData.id,
          Model: deviceData.model,
          Region: deviceData.region,
          Status: 'online',
          "Last Seen": new Date().toISOString()
        }}]
      })
    }
  );
  const newRecord = await create.json();
  return newRecord.records[0];
}

deploy the function, set env vars, point cloudf.one’s webhook at the function URL. events flow into Airtable and link automatically across the three tables.

if you prefer no-code, the same logic in cloud phone Zapier integration achieves the same result.

pattern 1: live fleet status interface

Airtable’s Interface Designer turns the Devices table into a dashboard. drag in a grid view filtered to “Status is offline,” add a stat block showing “Total devices,” and grouped by Region.

the result is a real-time fleet health dashboard accessible to anyone on your team via the Airtable interface. ops engineers see device health at a glance without opening the cloudf.one dashboard.

pattern 2: customer support reference

when a customer asks about their cloud phone history, support opens the Devices table, searches by email (in Owner -> Customer), and clicks into the linked record.

the device record shows:

support has a complete view of the customer’s cloud phone history without needing engineering access.

pattern 3: SLA monitoring with Airtable Automations

Airtable Automations triggers when the Events table receives a new record where Status = “failed”. the automation:

  1. checks how many failures the same device has had in the last 24 hours
  2. if more than 3, creates a high-priority record in an SLA Breaches table
  3. sends a Slack message to #sla-alerts
  4. assigns the breach to the on-call engineer

this turns Airtable into an SLA monitoring system without writing custom alerting infrastructure.

authoritative reference on Airtable’s API is the Airtable Web API documentation.

scaling considerations

Airtable’s API rate limit is 5 requests per second per base. for typical cloud phone ops, this is enough.

for high-volume fleets, consider:

most teams never approach the rate limit. Airtable scales further than people expect.

try cloud phone Airtable tracking on a real Singapore device

if you use Airtable for ops and want a structured tracking system for cloud phone activity, start a trial, generate an API token, and wire your first webhook in 30 minutes.

frequently asked questions

can I build Airtable interfaces for non-technical team members?

yes. Airtable Interface Designer lets you build read-only or interactive interfaces from your data. ops engineers, customer support, and account managers can each have a dedicated interface tailored to their needs.

what’s the latency between a cloud phone event and the Airtable entry?

typically under 5 seconds end-to-end. cloudf.one fires the webhook within 100ms, the bridging function processes within 1 second, and Airtable’s API responds within 1 to 3 seconds.

can I sync Airtable changes back to cloudf.one?

yes. Airtable Automations can fire webhooks to your serverless function on record updates. for example, marking a device as “maintenance” in Airtable triggers a cloudf.one API call to lock that device.

how does Airtable handle the volume of cloud phone events?

Airtable’s per-base record limit on the Pro plan is 50,000. for high-volume event logging, archive older events to a separate base monthly, or write directly to a database (Postgres, BigQuery) and sync summaries to Airtable.

can I filter and group events the way Notion does?

yes, and arguably better. Airtable’s grouping, sorting, and filtering are more powerful than Notion’s, with formula and rollup fields for computed values.