Authentication and errors
The API contract defines access permissions, acceptance and result interpretation.
Authentication and calling conventions
Cloud Mobile Core HTTP API for trusted servers, administrator workbenches, and restricted business sessions. Fields use snake_case; resource IDs are strings; timestamps use UTC RFC3339.
Default authentication: send both X-Core-Key and X-Core-Secret with every request. Ordinary business endpoints also accept Authorization: Bearer <restricted-session-token>. These authentication methods are mutually exclusive and must not be combined. x-core-public means an endpoint is available to restricted business sessions; it does not mean anonymous access. Service-credential and session-management endpoints accept Key/Secret only. Health checks require no credentials, and file-transfer links use their own short-lived tickets.
Reading status: a Cloud Phone's status describes its container, while wifi_status describes observed network availability. Show a phone as operational only when both are running. Common device values are created / running; handle offline, missing observations, and other provider states according to the field descriptions.
Device actions are asynchronous tasks: HTTP 202 means only that Core has durably accepted the task. Query task_id afterward and inspect items[] for per-target results. Task success alone does not prove that a Cloud Phone is online, streaming is available, or a backup has been delivered. Check the action result, observation, and file ready status together. If the outcome is unknown, query the original task or original Idempotency-Key; do not automatically repeat a device write with a new key. Core always executes device operations through a registered machine room.
X-Core-Key
Key for default service authentication. Must be supplied with X-Core-Secret, for trusted servers or an administrator's standalone workbench. Cannot be combined with Bearer authentication.
X-Core-Secret
Secret for default service authentication. Must be supplied with X-Core-Key. Do not embed it in public source code, URLs, or frontend configuration for ordinary business users.
bearer
Optional restricted opaque access token, created by a trusted server using Key/Secret and limited by Cloud Cards, permissions, and expiry. Accepted by ordinary business APIs, but not management APIs. Do not also send service Key/Secret.
Common error fields
Standard error response. status is the HTTP error code, not a Cloud Phone or Task status. Branch on code; detail may be displayed to users, and request_id correlates logs.
| Field | What it does |
|---|---|
type | Problem type identifier (URI), describing the category of error. |
title | Short title for the error type. |
status | HTTP status code for this error response, for example: 401=unauthenticated; 403=forbidden; 404=not found; 409=version or resource conflict; 422=invalid parameters or unmet business preconditions; 5xx=server or dependency failure. This is neither a Cloud Phone status nor a Task status. |
code | Stable, machine-readable error code for programmatic handling. This is an open string; clients must tolerate new codes. |
detail | Specific explanation of this error. It may be shown to users, but must not be used as a stable basis for program logic. |
request_id | Correlation ID for this HTTP request, used to trace logs. It is neither a Task ID nor an idempotency key. |
errors | Optional structured error details. The content depends on the error code. |
invalid_params | Field-specific validation errors, suitable for display beside form inputs. |