Connection contract
An assistant needs a terminal that can runruncloud, or a Node.js runtime that
can use @run-cloud/sdk. Use the released CLI and SDK rather than implementing
their underlying HTTP calls yourself. The default API origin is
https://api.run.cloud.
The local adapter is an Agent2Agent (A2A) protocol connection, distinct from
calling the CLI or SDK directly. It is not a hosted public A2A endpoint or
MCP server. A platform must be able to run it alongside the calling agent;
contact [email protected] if it requires a remote URL.
Standard Agent2Agent connection
The public A2A simulator example uses the official@a2a-js/sdk client and server with the published run.cloud
SDK. Start it locally with Node.js 20 or newer:
http://127.0.0.1:3100/.well-known/agent-card.json and
advertises the A2A 1.0 JSON-RPC endpoint at /a2a. Every operation requires
the caller’s own run.cloud API key as a Bearer credential. The adapter never
substitutes an operator’s key. Keep it on loopback; do not expose it as an
unsecured public service.
Send one structured data part, for example:
account, usage, create, get, open-url,
accessibility, tap, press-button (Home), screenshot, and delete.
Existing-device operations take platform and sessionId. Creation enforces
a five-minute hard limit and a 60-second inactivity timeout. The calling agent
must release its session in finally and preserve allocation IDs on retries.
The adapter returns immediate messages; it does not advertise streaming or
persistent tasks. The calling agent maps user prompts into these operations.
Account authentication does not authorize wallet payments, and this example
does not initiate a payment.
Account registration and authentication
Each integration uses the customer’s own run.cloud account and credential. There is no shared reviewer account or public API key.- Sign in or create an account at run.cloud/login. Email sign-in requires access to the verification inbox.
- Select the organization that will own the sessions and pay for their usage. Check membership before creating resources. If the account has no organization, resolve account setup with support before proceeding.
- For an SDK integration, create a named API key in the
dashboard and store it in your platform’s secret
store as
RUN_CLOUD_API_KEY. Never put it in a prompt, URL, or source file. - For CLI use, sign in once or inject that API key into the tool’s environment.
RUN_CLOUD_API_URL=https://api.run.cloud alongside RUN_CLOUD_API_KEY and skip
the login command. See Install the CLI.
Check SDK credentials with cloud.credential(), account memberships with
cloud.account(), and cumulative usage with cloud.usage({ orgId }). Keep
credentials isolated between users; never substitute the connector operator’s
credential when a user’s key fails.
For a fully automated registration check, the public example includes an
opt-in harness for an authorized Purelymail inbox. It requests a fresh signup
code, reads only mail addressed to its new tagged alias over TLS IMAP, creates
an account and API key, and checks CLI, SDK, and A2A authentication. Follow its
registration instructions.
Never give an agent inbox access without the owner’s authorization.
The redacted verification report
records a successful fresh registration against the public API with no manual
code entry, including rejection of missing and invalid credentials. That run
made no payment and created no simulator; it is registration/authentication
evidence, not proof of wallet approval or a paid session.
Billing and payment authorization
Sessions use the selected organization’s run.cloud billing. Funding an account and consuming simulator time are separate events: account credit is not a fixed-duration session purchase. Usage is metered while a session is active; releasing it stops future metering. Review billing access and available credit in the dashboard before allocating. The CLI and SDK described here do not expose an agent-wallet top-up operation. Do not interpret a payment-required error as a payable MPP or x402 challenge, or assume that a checkout URL means funds have arrived. A platform requiring agent-executed Link, MPP, or x402 funding must confirm that payment integration with [email protected] before promising an unattended signup-to-paid-session flow. Never retry a charge blindly after a timeout. Authentication success, account credit, recorded usage, and a settled payment are different checks. Report them separately. See Access Control and Metering and Limits.Runnable simulator workflow
Install@run-cloud/sdk in a Node.js 20+ project:
RUN_CLOUD_API_KEY: the customer’s secret API key.RUN_CLOUD_ORG_ID: the organization selected from the account’s memberships.RUN_CLOUD_REQUEST_ID: a unique ID for this allocation. Preserve it when retrying a request whose response was lost; use a new ID for a new allocation.SIMULATOR_PLATFORM:ios(default) orandroid.
simulator-review.mjs and run node simulator-review.mjs.
It creates one metered session, opens a website, captures the screen, presses
Home, captures the result, and releases the device even if an interaction fails.
Map requests to tools
Tap coordinates are normalized:
(0, 0) is the upper-left corner and (1, 1)
the lower-right. See Simulator controls,
Open URLs, and SDK reference for the full
argument and response types. Install your own app using a simulator-compatible
iOS build or Android APK; see iOS sessions and
Android sessions.
Suggested review prompts
These prompts describe requests to map to the tools above; they do not imply approval or compatibility with any particular assistant platform.- “Connect my run.cloud account and check which organization I can use. Keep my API key private.”
- “Start an iOS simulator on run.cloud with a five-minute maximum lifetime. Give me its session ID and privately share its viewer link.”
- “Open https://run.cloud on that simulator and show me a screenshot.”
- “Press Home on the simulator and show me the resulting screen.”
- “End my simulator session, confirm it was released, and report recorded usage separately from payment status.”
Review checklist
- Missing or invalid credentials cannot create or control a session.
- The authenticated user belongs to the selected organization.
- Allocation retries use the same idempotency key; unrelated requests do not.
- The session becomes usable and screenshots confirm the requested interactions.
- The session is released on success and on failure, with an inactivity timeout and a hard lifetime limit as backstops.
- Keys, verification codes, signed URLs, and private screen contents stay out of public transcripts.
- A paid-flow claim includes confirmed account funding and recorded simulator usage; neither successful login nor a generated checkout link is sufficient.