how to use cloud phones with Bubble in 2026

May 07, 2026

how to use cloud phones with Bubble in 2026

a cloud phone Bubble integration is what teams build when they want to ship a customer-facing app on top of cloudf.one without writing a backend. Bubble’s API Connector handles the cloud phone REST calls, Bubble’s backend workflows handle the webhook receivers, and Bubble’s database stores the device state. the result is a fully functional no-code app that lets your customers self-serve cloud phone access.

this guide walks through wiring cloudf.one into Bubble step by step, with three real working patterns you can copy into your app.

what cloudf.one and Bubble bring together

cloudf.one’s API surface for Bubble:

REST endpoints for device control (lock, unlock, reboot, install, screenshot)
webhook events for state changes
standard JSON request/response

Bubble’s matching capabilities:

API Connector plugin (configure REST endpoints as Bubble actions)
backend workflows (receive webhooks, process events, update database)
frontend workflows (trigger actions from button clicks)
privacy rules (control which users can trigger which device actions)

the result is a Bubble app where a customer logs in, sees their cloud phone in a dashboard, and controls it through Bubble’s UI without ever touching the cloudf.one dashboard directly.

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

step 1: install the API Connector and add cloudf.one

in Bubble’s editor, go to Plugins -> Add plugins -> install API Connector. open the API Connector and create a new API:

name: cloudfone API
authentication: HTTP Header Authentication
header name: Authorization
header value: Bearer cf_live_xxxxxxxxxxxxxxxxxxxx

now add API calls. each call corresponds to a cloudf.one endpoint.

step 2: configure the device control calls

example call: List Devices

method: GET
URL: https://api.cloudf.one/v1/devices
response type: JSON

click “Initialize call” and Bubble fetches the response, auto-detecting the JSON schema. you now have a cloudfone API - List Devices action available throughout your app.

example call: Lock Device

method: POST
URL: https://api.cloudf.one/v1/devices/[device_id]/lock
body type: JSON
body: {}

mark device_id as a parameter. Bubble exposes it as an input when you use the action.

repeat for unlock, reboot, install APK, and any other endpoints you need.

step 3: build the customer dashboard

create a new page in Bubble called Dashboard. add elements:

a Repeating Group bound to “Get data from external API -> cloudfone API - List Devices”
inside each cell, display the device model, status, and a button group (Lock, Unlock, Reboot)
on each button click, trigger the corresponding cloudfone API action with the device’s ID

the customer sees their cloud phone fleet, clicks a button, and the cloud phone responds within a few seconds. zero backend code on your side.

pattern 1: customer self-service device provisioning

the most common Bubble integration. customer signs up, pays, and Bubble provisions a cloud phone automatically.

workflow steps:

customer completes signup form
Bubble triggers Stripe payment
on payment success, Bubble triggers the cloudf.one provision API
on success response, Bubble creates a Device record in the database with the customer as owner
Bubble sends the customer a welcome email with credentials

the cloudf.one provision call body:

{
  "owner_email": "[Current User's email]",
  "plan": "[Current User's plan]",
  "region": "SG",
  "send_credentials_email": false
}

Bubble receives the device ID, username, and password in the response. it stores those in the database and includes them in the welcome email.

similar pattern in cloud phone Zapier integration, but Bubble keeps the entire customer-facing experience inside one platform.

pattern 2: receive cloud phone events into Bubble’s database

Bubble’s backend workflows can act as webhook receivers. configure cloudf.one to send events to a Bubble backend endpoint.

create a new backend workflow:

detect data type: request data
expose as a public API workflow: yes
parameters: define keys matching the cloudf.one webhook payload (event, timestamp, device.id, device.model, etc.)

the resulting URL looks like:

https://yourapp.bubbleapps.io/api/1.1/wf/cloudfone-event

paste this into cloudf.one’s webhook configuration. select which events to subscribe to.

inside the backend workflow, parse the event and update the relevant Device record. for example, on device.offline, set the Device’s status field to “offline” and create an Alert record for the device owner.

pattern 3: in-app screenshot viewer

let customers take a screenshot of their cloud phone from inside Bubble.

frontend workflow on a “Take Screenshot” button:

trigger cloudfone API - Take Screenshot action with the device’s ID
the API returns a URL to the screenshot file
Bubble displays the image in a Picture element
optionally, Bubble saves the screenshot URL to the customer’s screenshot history

backend workflow for batch processing:

if the customer takes many screenshots, run the actual download in a backend workflow to avoid blocking the UI:

frontend workflow triggers backend workflow with screenshot URL
backend workflow downloads the image, uploads to Bubble’s file storage
updates the Screenshot record with the persistent URL

privacy rules for multi-tenant cloud phone apps

Bubble’s privacy rules ensure that customer A cannot see or control customer B’s devices. configure on the Device data type:

“Find this in searches” condition: Current User’s email is This Device’s owner_email
“View all fields” condition: same
“Modify via API” condition: same

now even if a malicious customer tries to call your Bubble API workflows with another customer’s device ID, the privacy rules block the request.

authoritative reference on Bubble’s API Connector is the Bubble API Connector docs.

performance and rate limiting

Bubble apps make API calls from the server side, which means they share a rate limit pool with all your users. for high-volume cloud phone integrations, consider:

caching device list responses for 30 to 60 seconds
using Bubble’s Scheduled API Workflows for batch operations (instead of synchronous calls from the UI)
queueing webhook processing in batches of 50 to 100

cloudf.one’s API rate limit is 1000 requests per minute per token. Bubble’s outbound API calls fit comfortably within that for typical SaaS patterns.

try cloud phone Bubble integration on a real Singapore device

if you build no-code apps in Bubble and want to add cloud phone functionality, start a trial, generate an API token, and configure your first API Connector calls in 30 minutes.

frequently asked questions

do I need a paid Bubble plan to use the API Connector?

the API Connector is available on Bubble’s free plan. for production apps with custom domain, scheduled workflows, and adequate workload units, a paid plan is required.

can Bubble handle the volume of cloud phone webhooks?

Bubble’s backend workflows handle moderate webhook volume (up to 1,000 per hour comfortably). for higher volume, consider buffering webhooks through a service like Hookdeck before forwarding to Bubble.

how do I let customers ADB into their cloud phone from Bubble?

ADB requires a TCP connection, which Bubble’s frontend can’t open directly. expose an ADB tunnel URL through the cloudf.one API and provide it to the customer for use with their local ADB client.

can I white-label the cloud phone experience inside my Bubble app?

yes. by handling all device control through your Bubble UI and the cloudf.one API, your customers never see the cloudf.one brand. the cloud phone becomes a feature of your product.

is there a Bubble plugin for cloudf.one?

a native Bubble plugin is on the roadmap. the API Connector approach covers all common patterns and gives you full control over the integration.