how to connect cloud phones to n8n workflows
how to connect cloud phones to n8n workflows
a cloud phone n8n integration is what teams reach for when Zapier’s task limits get expensive or when the workflow needs to stay self-hosted for compliance reasons. n8n runs on your own infrastructure (or n8n Cloud), supports the same webhook and HTTP request patterns Zapier does, and gives you full control over the data flow.
this guide walks through wiring cloudf.one into n8n with three real working examples and the correct error handling patterns.
what cloudf.one and n8n bring to the table
cloudf.one’s API surface for automation:
- REST endpoints for device control: lock, unlock, reboot, install APK, screenshot
- webhook events for state changes: device.locked, device.unlocked, device.offline, install.completed
- ADB-over-network for direct shell-level commands
n8n’s matching capabilities:
- Webhook node (catches incoming HTTP requests as triggers)
- HTTP Request node (makes outbound API calls, including to cloudf.one)
- 350+ built-in nodes for downstream actions (Slack, Notion, Postgres, Telegram, etc.)
- Code node (run JS or Python for custom logic)
n8n’s strength versus Zapier is the JavaScript/Python code nodes and the unlimited-execution self-hosted option. for cloud phone ops at scale, the cost difference is significant.
for the broader case on cloud phone integrations, see cloud phone CI/CD integration.
step 1: provision API access
generate a cloudf.one API token from the dashboard. in n8n, go to Credentials -> Create New -> Header Auth and configure:
- name: cloudfone API
- header name: Authorization
- header value:
Bearer cf_live_xxxxxxxxxxxxxxxxxxxx
now any HTTP Request node can reference this credential without exposing the token in the workflow JSON.
step 2: configure a webhook trigger
create a new workflow in n8n. add a Webhook node as the trigger. set:
- HTTP method: POST
- path:
cloudfone-events - authentication: header auth (optional, recommended)
- response: immediately
n8n generates a webhook URL like:
https://your-n8n.example.com/webhook/cloudfone-events
paste this URL into cloudf.one’s webhook configuration in the dashboard. select the events you want to receive.
step 3: test with a sample payload
trigger a test event by manually locking a device. n8n captures the incoming payload and shows it in the workflow editor. example:
{
"event": "device.locked",
"timestamp": "2026-05-07T08:30:00+08:00",
"device": {
"id": "dev_8a1b2c3d",
"model": "Samsung Galaxy A24",
"android_version": "14",
"region": "SG"
},
"session": {
"id": "sess_x9y8z7",
"user_id": "user_5e6f7g"
}
}
you can now reference this data in downstream nodes using n8n’s expression syntax: {{ $json.device.model }}.
example workflow 1: route device events to Telegram with smart filtering
a common ops pattern. webhook receives all device events, an IF node filters for the events that matter, and Telegram sends a notification.
[Webhook: cloudfone-events]
-> [IF: event in (device.offline, install.failed)]
true -> [Telegram: send message]
false -> [stop]
the IF node condition:
{{ $json.event === "device.offline" || $json.event === "install.failed" }}
the Telegram message template:
Cloud phone alert
Event: {{ $json.event }}
Device: {{ $json.device.model }} ({{ $json.device.id }})
Region: {{ $json.device.region }}
Time: {{ $json.timestamp }}
ops team gets only the alerts that need action. no noise.
example workflow 2: scheduled daily APK install across the fleet
n8n’s Cron trigger fires every weekday at 02:00 SGT. the workflow installs the latest nightly build on every device in the staging pool.
[Cron: 0 2 * * 1-5]
-> [HTTP Request: GET /v1/devices?tag=staging]
-> [Split In Batches: batch size 5]
-> [HTTP Request: POST /v1/devices/{{ $json.id }}/install]
-> [Wait: 30 seconds]
-> [Slack: report completion]
the install POST body:
{
"apk_url": "https://artifacts.your-ci.com/staging-latest.apk",
"auto_launch": true,
"wait_for_completion": true
}
each device gets the latest build with a 30-second pause between installs to avoid overwhelming the fleet. completion reports go to Slack with success/failure counts.
similar pattern with full code in cloud phone CI/CD integration.
example workflow 3: provision new device when Stripe customer pays
the most common revenue-side automation. Stripe webhook triggers, n8n creates the cloud phone, sends welcome email.
[Webhook: stripe-events]
-> [IF: event = customer.subscription.created]
-> [HTTP Request: POST /v1/devices/provision]
-> [HTTP Request: GET customer details from Stripe]
-> [Email: send welcome with credentials]
-> [Notion: create customer record]
the cloudf.one provision request:
{
"owner_email": "{{ $json.data.object.customer_email }}",
"plan": "{{ $json.data.object.items.data[0].price.lookup_key }}",
"region": "SG",
"send_credentials_email": false
}
cloudf.one returns the credentials in the response. the email node uses those to send the welcome message with login details. the Notion node logs the new customer to your CRM.
error handling pattern
cloudf.one’s API can return errors (rate limit, device unavailable, network blip). n8n’s “Continue On Fail” setting plus an error workflow handles these gracefully.
set Continue On Fail to true on the HTTP Request node. add a downstream IF node:
{{ $node["HTTP Request"].error !== undefined }}
route the error path to a retry queue (Postgres, Redis) or a Slack channel for manual investigation. the success path continues normally.
for production-grade error handling, n8n supports global Error Workflows that catch any uncaught exception across all workflows. configure once, applies everywhere.
authoritative reference on n8n error handling is the n8n error workflow documentation.
self-hosted vs n8n Cloud
n8n self-hosted: free, runs on your own infrastructure, unlimited executions. ideal for high-volume cloud phone ops or compliance-sensitive workloads.
n8n Cloud: managed service with usage-based pricing. ideal if you don’t want to maintain the infrastructure and your workflow volume is moderate.
both options work identically for cloud phone integration. the API and webhook patterns are the same.
try cloud phone n8n integration on a real Singapore device
if you run n8n and want to integrate cloud phones into your automation flows, start a trial, generate an API token, and connect your first webhook node in 15 minutes.
frequently asked questions
can I run n8n on the same server as my cloud phone provisioning?
n8n is lightweight and runs fine on the same VPS or Docker host as other tools. for cloud phone ops, n8n only talks to cloudf.one over HTTPS, so there’s no co-location requirement.
how do I handle webhook authentication in n8n?
use n8n’s built-in header auth on the Webhook node. add a shared secret as a custom header that cloudf.one sends with every webhook. n8n rejects requests without the correct header.
can I trigger ADB commands on cloud phones from n8n?
yes. cloudf.one exposes an ADB-over-HTTP endpoint that accepts shell commands. POST the command to /v1/devices/{id}/adb/shell and n8n receives the output in the response.
what’s the throughput limit for n8n + cloud phone webhooks?
cloudf.one’s webhook delivery rate is unbounded for typical fleet sizes. n8n’s processing rate depends on your hosting. self-hosted n8n on a 4-core VPS handles 100+ webhook executions per second comfortably.
can I use n8n to run cross-platform automation (cloud phone + Slack + Notion + Postgres)?
yes. n8n has 350+ built-in nodes covering most SaaS tools, databases, and APIs. cloud phone ops typically span 4 to 8 different tools, all of which n8n connects natively.