> ## Documentation Index
> Fetch the complete documentation index at: https://docs.phoneuse.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Report the run's outcome

> How a worker says it is done. It lives on this surface rather than on the run surface because a worker holds exactly one credential, its run token, and should never need an org credential to close its own work. The token also pins WHICH run is being reported, so a worker cannot close somebody else's.

`needs_user_control` parks the run for a person, who lifts it through the run surface. Secrets never travel in this body.

Once a run is parked, only a person can end it: a `succeeded` or `failed` report on a parked run is refused with a 409 until someone resumes or cancels it. Reporting `needs_user_control` again is allowed and only refreshes the handoff instruction.

This operation reads no `Authorization` header. The run token in the path IS the credential, so the whole url is secret: never log it, paste it, or commit it. Every example writes `{runToken}` for that reason.



## OpenAPI

````yaml /api/openapi.json post /vrx/{runToken}/v1/report
openapi: 3.1.0
info:
  title: Phonebase HTTP API
  version: 0.1.0
  summary: >-
    Every HTTP operation the control plane mounts, generated from the app's own
    route table.
  description: >-
    The control plane exposes two HTTP surfaces, and reading the boundary
    between them matters more than reading any single endpoint.


    The CONTROL surface is what your backend and your operators call. It takes a
    bearer token in the `Authorization` header, and two credential channels
    resolve to the same authorization context: an OAuth 2.1 access token for
    interactive clients, or an org scoped API key for headless ones.


    The DEVICE surface, under `/vrx/{runToken}/v1`, is what a worker calls while
    executing one run. Its credential is the run token in the url path, and it
    reads no `Authorization` header at all.


    Device control itself is not REST. An agent taps, swipes and reads the
    screen over the Model Context Protocol at `POST /mcp`, one tool call at a
    time. There is no `POST /v1/devices/{id}/tap`, and if you are looking for
    one, start with the tool reference instead.


    Operations marked `"x-phonebase-modes": ["hosted"]` exist only on a hosted
    deployment; a local checkout does not mount them.
servers:
  - url: '{origin}'
    description: Your control plane origin.
    variables:
      origin:
        default: https://mcp.phonebase.co
        enum:
          - https://mcp.phonebase.co
          - http://127.0.0.1:8788
        description: >-
          The hosted deployment serves the public origin its metadata document
          advertises, and that is the default here. Select the loopback entry
          instead when you are running a local checkout, which serves the port
          `PORT` names.
security: []
tags:
  - name: Apps
    description: Save immutable application builds and manage explicit device operations.
  - name: Managed Proxy
    description: >-
      Organization-owned fixed egress resources, independent one-time orders and
      verified network relationships.
  - name: Health
    description: Liveness, unauthenticated.
  - name: Gateway enrollment
    description: >-
      How a new gateway computer trades a one-time enrollment code for its
      tunnel credential. Unauthenticated: the code is the credential.
  - name: Gateway releases
    description: >-
      What a gateway computer installs: the current edge release of a channel.
      Called with the gateway's own credential.
  - name: MCP
    description: The JSON-RPC endpoint an agent drives devices through.
  - name: Copilot
    description: >-
      Drive a device by chatting. A signed in person's own conversations,
      streamed. Hosted deployments only.
  - name: Discovery
    description: Where to authenticate. Served on hosted deployments only.
  - name: Runs
    description: Start, watch and steer a run.
  - name: API keys
    description: Mint and revoke headless credentials. Hosted deployments only.
  - name: Device surface
    description: What a worker calls with its run token to observe and act.
  - name: Usage
    description: Read your org's own receipts and consumption. Hosted deployments only.
  - name: Devices
    description: Read the fleet your credential can see. Hosted deployments only.
  - name: Notifications
    description: >-
      What a person needs to know when they are not watching, and which emails
      they receive. Hosted deployments only.
  - name: Webhooks
    description: >-
      Subscribe your own system to what happens here, and read what was
      delivered. Hosted deployments only.
  - name: Provisioning
    description: >-
      Whether an organisation is provisioned, and how it becomes so. Hosted
      deployments only, and both operations answer a declared 503 on a
      deployment that cannot provision yet.
paths:
  /vrx/{runToken}/v1/report:
    post:
      tags:
        - Device surface
      summary: Report the run's outcome
      description: >-
        How a worker says it is done. It lives on this surface rather than on
        the run surface because a worker holds exactly one credential, its run
        token, and should never need an org credential to close its own work.
        The token also pins WHICH run is being reported, so a worker cannot
        close somebody else's.


        `needs_user_control` parks the run for a person, who lifts it through
        the run surface. Secrets never travel in this body.


        Once a run is parked, only a person can end it: a `succeeded` or
        `failed` report on a parked run is refused with a 409 until someone
        resumes or cancels it. Reporting `needs_user_control` again is allowed
        and only refreshes the handoff instruction.


        This operation reads no `Authorization` header. The run token in the
        path IS the credential, so the whole url is secret: never log it, paste
        it, or commit it. Every example writes `{runToken}` for that reason.
      operationId: postVrxByRunTokenV1Report
      parameters:
        - name: runToken
          in: path
          required: true
          description: The run token. Write `{runToken}`; never write a real one down.
          schema:
            type: string
      requestBody:
        description: The outcome, and optionally what happened.
        required: true
        content:
          application/json:
            schema:
              type: object
              properties:
                state:
                  type: string
                  enum:
                    - succeeded
                    - failed
                    - needs_user_control
                  description: The outcome being reported.
                detail:
                  type: string
                  description: >-
                    Free text. No VALUE of this field is refused: long values
                    are truncated at 4000 characters (on a character boundary,
                    so an emoji is not split), a NUL (U+0000) is replaced with
                    U+FFFD because it cannot be stored, and every other
                    character is recorded verbatim. A report is a run reaching
                    its terminal state, so a refusal here would strand the run.
                    The one limit that still applies is the request-wide 1 MiB
                    body cap, which is a transport limit and answers 413 before
                    this field is read: keep the whole request under it, or the
                    run does not terminate.
              required:
                - state
              additionalProperties: false
      responses:
        '200':
          description: The report was recorded.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Ok'
        '400':
          description: >-
            The body is not JSON, or `state` is not one of the reportable
            states.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/DeviceError'
        '404':
          description: >-
            Unknown, expired, terminal, or addressed at a device this run does
            not own. All four answer identically, so holding a token tells you
            nothing about which it was.


            If you reached this with an org API key rather than a run token, the
            code is misleading and the message says so: nothing is missing, this
            is the worker channel and your credential does not apply to it.
            Drive devices yourself over the MCP endpoint instead.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/DeviceError'
        '409':
          description: >-
            The run is parked for a person: a worker cannot end its own handoff,
            so only resume or cancel lifts it.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/DeviceError'
        '413':
          description: >-
            The request body exceeds the server's limit (1 MiB). Refused before
            the body is parsed, so nothing was partially applied. Retrying the
            same body will fail the same way: send less. Per-field limits are
            tighter than this and are documented on the fields themselves; this
            is the backstop underneath them. The shape is the same on ordinary
            JSON surfaces, /vrx included. The explicitly configured APK content
            stream documents its own byte ceiling.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/PayloadTooLargeError'
        '429':
          description: >-
            Over the request budget for this caller. Hosted deployments only.
            Which budget applied depends on whether this request carried an
            `Authorization` header, not on which endpoint it was aimed at. Wait
            `Retry-After` seconds and retry the same request: the refusal
            happens before any work, so nothing was partially applied. See
            /api/rate-limits.
          headers:
            Retry-After:
              description: >-
                Whole seconds until one request is available again. Computed
                from the caller's own remaining allowance, not a fixed constant.
              schema:
                type: string
            RateLimit-Limit:
              description: >-
                The budget in effect for this caller class, in requests per
                minute.
              schema:
                type: string
            RateLimit-Remaining:
              description: >-
                Whole requests that were still available when this request was
                admitted. Zero on a 429.
              schema:
                type: string
            RateLimit-Reset:
              description: >-
                Seconds until the allowance is back to full. Longer than
                `Retry-After`, which is the wait for a single request.
              schema:
                type: string
            RateLimit-Policy:
              description: The budget and its window, as `<limit>;w=60`.
              schema:
                type: string
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/RateLimitedError'
      security: []
components:
  schemas:
    Ok:
      type: object
      properties:
        ok:
          type: boolean
      required:
        - ok
      additionalProperties: false
    DeviceError:
      type: object
      properties:
        ok:
          type: boolean
          const: false
        error:
          type: object
          properties:
            code:
              type: string
              enum:
                - DEVICE_NOT_FOUND
                - INVALID_ACTION
                - FRAME_VIEWPORT_MISMATCH
                - COORDINATE_OUT_OF_REACH
                - ACTION_UNAVAILABLE
                - FENCING_TOKEN_STALE
                - STALE_FRAME
                - HARDWARE_OFFLINE
                - FRAME_UNAVAILABLE
                - ACTION_OUTCOME_UNKNOWN
              description: The dialect code to branch on.
            message:
              type: string
              description: >-
                A constant summary per branch. Internal error text is never
                forwarded here.
            details:
              type: object
              description: >-
                Structured detail for the branches that have any (spec §8,
                §15.4). `STALE_FRAME` carries `reason` (`unknown_frame`,
                `superseded`, `expired`, `viewport_changed`, `others_acted`;
                read anything else as `unknown_frame`), and an
                `ACTION_UNAVAILABLE` raised by a full device queue carries
                `retryAfterMs`. Absent on every other branch, and it never
                carries internal text.
              additionalProperties: true
          required:
            - code
            - message
          additionalProperties: false
      required:
        - ok
        - error
      additionalProperties: false
      description: >-
        The device surface answers in the dialect's own error shape, not the
        control surface envelope.
    PayloadTooLargeError:
      type: object
      properties:
        error:
          type: object
          properties:
            code:
              type: string
              const: payload_too_large
              description: Always `payload_too_large` on this response.
            message:
              type: string
              description: A human readable summary naming the limit in bytes.
          required:
            - code
            - message
          additionalProperties: false
      required:
        - error
      additionalProperties: false
      description: >-
        Returned when the request body exceeds the server limit. Identical on
        every surface, including /vrx.
    RateLimitedError:
      type: object
      properties:
        error:
          type: object
          properties:
            code:
              type: string
              const: rate_limited
              description: Always `rate_limited` on this response.
            message:
              type: string
              description: >-
                A human readable summary. The numbers are in the headers, not in
                here.
          required:
            - code
            - message
          additionalProperties: false
      required:
        - error
      additionalProperties: false
      description: >-
        Over the request budget. Raised by the rate limiter before any handler
        runs, which is why its code is not one of the action codes: nothing was
        attempted, so no action failed.

````

This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.