how to connect cloud phones to Zapier in 2026
how to connect cloud phones to Zapier in 2026
a cloud phone Zapier integration looks complicated until you realize cloud phones expose a clean REST API and Zapier supports webhooks both ways. once those two facts click, the integration becomes a one-afternoon project that automates everything from “lock a phone when a customer signs up” to “post a Slack alert when a phone reboots unexpectedly.”
this guide walks through the actual mechanics: how to authenticate, how to trigger Zapier from a cloud phone event, how to drive cloud phone actions from Zapier, and three working example zaps you can copy.
what cloudf.one exposes that Zapier can use
cloudf.one’s API surface that matters for Zapier integration:
- REST endpoints for device control: lock, unlock, reboot, install APK, screen recording, screenshot
- webhook events for device state changes: device locked, device unlocked, device offline, device online, install completed, install failed
- ADB-over-network endpoints for direct device commands
Zapier’s matching capabilities:
- webhooks by Zapier (catches incoming webhooks as triggers)
- webhooks by Zapier (sends outgoing webhooks as actions)
- the broader Zapier app catalog (Slack, Notion, Airtable, Gmail, etc.) for downstream actions
the connection layer is webhooks both ways. cloud phone fires a webhook to Zapier, Zapier processes the event, Zapier fires actions in any of its 5,000+ supported apps. or Zapier triggers from any of those apps and fires a webhook back to cloud phone to take an action.
for the broader case why integration matters for cloud phone ops, see cloud phone CI/CD integration.
step 1: get your cloudf.one API token
log into the cloudf.one dashboard, go to Settings -> API Tokens, and generate a new token. copy it somewhere safe. this token authenticates every API request.
export CLOUDFONE_TOKEN="cf_live_xxxxxxxxxxxxxxxxxxxx"
verify the token works:
curl -H "Authorization: Bearer $CLOUDFONE_TOKEN" \
https://api.cloudf.one/v1/devices
you should see a JSON response listing the devices in your fleet.
step 2: register a webhook endpoint
cloudf.one needs to know where to send events. in the dashboard, go to Settings -> Webhooks and add a new endpoint URL.
for Zapier-bound webhooks, the URL comes from a Zapier “catch hook” trigger. create a new zap, choose “Webhooks by Zapier” as the trigger, choose “Catch Hook,” and Zapier generates a URL like:
https://hooks.zapier.com/hooks/catch/12345678/abcdefg/
paste this into cloudf.one’s webhook config, and select which events to subscribe to (device.locked, device.unlocked, device.offline, install.completed, etc.).
step 3: send a test event
trigger a test event by manually locking a device in the dashboard. cloudf.one sends a payload like this to your Zapier hook:
{
"event": "device.locked",
"timestamp": "2026-05-07T08:30:00+08:00",
"device": {
"id": "dev_8a1b2c3d",
"model": "Samsung Galaxy A24",
"android_version": "14",
"region": "SG",
"imei": "353xxxxxxxxxxx"
},
"session": {
"id": "sess_x9y8z7",
"user_id": "user_5e6f7g",
"locked_at": "2026-05-07T08:30:00+08:00"
}
}
Zapier shows the captured payload in the trigger setup screen. you now have a live trigger you can build actions on top of.
example zap 1: alert Slack when a device goes offline
trigger: Webhooks by Zapier - Catch Hook (subscribed to device.offline events)
action: Slack - Send Channel Message
the action template uses the device data from the trigger:
Device offline alert
Model: {{device__model}}
ID: {{device__id}}
Region: {{device__region}}
Last seen: {{timestamp}}
Investigate: https://app.cloudf.one/devices/{{device__id}}
post the message to a #cloudfone-ops Slack channel. anyone on the ops team sees the alert within seconds of the device dropping offline.
similar pattern works for any of the cloud phone events. you can trigger different Slack channels based on event type using filters.
example zap 2: provision a cloud phone when a Stripe customer subscribes
trigger: Stripe - New Customer (subscribed to a specific product)
action: Webhooks by Zapier - POST
URL: https://api.cloudf.one/v1/devices/provision
headers:
Authorization: Bearer cf_live_xxxxxxxxxxxxxxxxxxxx
Content-Type: application/json
body:
{
"owner_email": "{{customer_email}}",
"plan": "starter",
"region": "SG",
"send_credentials_email": true
}
the result: a Stripe customer subscribes to a starter plan, Zapier picks up the new customer event, and cloudf.one provisions a fresh cloud phone with credentials emailed to the customer. zero manual onboarding work.
example zap 3: log every install event to Airtable
trigger: Webhooks by Zapier - Catch Hook (subscribed to install.completed and install.failed events)
action: Airtable - Create Record
base: Cloud Phone Install Log table: Installs
field mapping:
Timestamp: {{timestamp}}
Device ID: {{device__id}}
Device Model: {{device__model}}
APK Package: {{install__package_name}}
APK Version: {{install__version}}
Status: {{event}}
Error: {{install__error}}
every install event across the fleet gets logged to Airtable for historical analysis. similar to the Notion event logging pattern in cloud phone Notion event logging.
driving cloud phone actions from Zapier
the reverse direction is just as useful. any Zapier trigger can drive a cloud phone action via the REST API. common patterns:
- a new row in Google Sheets triggers a cloud phone reboot
- a Notion task assignment triggers a cloud phone APK install
- a calendar event triggers a screen recording on a specific device
- a form submission triggers a cloud phone screenshot for marketing assets
each of these is a “Webhooks by Zapier - POST” action with the appropriate cloudf.one endpoint and payload.
error handling and retries
Zapier retries failed webhook deliveries automatically. cloudf.one’s webhook system also retries failed deliveries with exponential backoff (3 attempts over 5 minutes by default). if your Zapier hook is temporarily unavailable, the event will be delivered when it comes back online.
for high-volume integrations, consider using Zapier’s “Code by Zapier” action to add custom error handling, deduplication, or rate limiting before downstream actions fire.
authoritative reference on Zapier webhook handling is Zapier’s webhooks documentation.
try cloud phone Zapier integration on a real Singapore device
if you want to wire cloud phones into your existing Zapier workflows, start a trial, generate an API token, and connect your first webhook in 10 minutes.
frequently asked questions
do I need a paid Zapier plan to use cloud phone integration?
webhooks by Zapier is available on Zapier’s free and paid plans. for high-volume integrations or multi-step zaps, a paid plan unlocks more tasks per month.
what’s the latency between a cloud phone event and a Zapier-triggered action?
typically under 5 seconds end-to-end. cloudf.one fires the webhook within 100ms of the event, Zapier processes the trigger within 1 to 3 seconds, downstream actions fire shortly after.
can I use Zapier to install APKs on cloud phones?
yes. the cloudf.one REST API exposes an install endpoint that accepts an APK URL. trigger from any Zapier-supported source (a new Dropbox file, a new GitHub release, etc.).
is there a Zapier app for cloudf.one in the public catalog?
a public Zapier app integration is on the roadmap. in the meantime, the webhooks-based integration covers all the common patterns and is more flexible for custom logic.
can I rate-limit my cloud phone API calls from Zapier?
yes. use Zapier’s “Delay” action or Zapier’s built-in throttling settings on a paid plan. cloudf.one also rate-limits at the API layer (1000 requests per minute per token by default).