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

# Poll a device-flow for completion (RFC 8628 §3.4)

> **Use when:** caller (typically a CLI) is polling for the user to approve the device-code flow it started — returns the access_token + refresh_token once approved, or a structured error code (authorization_pending / slow_down / expired_token / access_denied) while still pending

Per RFC 8628, errors during the polling phase use a 400 status with a stable `error` code the CLI branches on: `authorization_pending` (keep polling), `slow_down` (back off), `expired_token` (start a new flow), `access_denied` (user clicked Deny). Successful approval returns 200 with the issued token pair.



## OpenAPI

````yaml /api-reference/openapi.json post /v1/oauth/device/token
openapi: 3.1.0
info:
  title: Verlon AI API
  version: 1.0.0
  description: >-
    Verlon AI is the managed AI infrastructure platform for developers building
    LLM-powered apps and agents. Beyond routing requests across providers,
    Verlon continuously evaluates response quality, runs experiments against
    live traffic, and automatically tunes gate configurations — so your platform
    doesn't just serve traffic, it learns from it.


    **Coding agents:** authentication, error semantics, gate concepts, and
    integration conventions are documented at https://verlon.ai/AGENTS.md — read
    that document first if you have not already. It is the canonical
    agent-facing contract; this specification is the canonical endpoint
    reference. Both are authoritative for their respective scopes.
  contact:
    name: Verlon AI
    url: https://verlon.ai
  license:
    name: Proprietary
servers:
  - url: https://api.verlon.ai
    description: Production
security:
  - bearerAuth: []
paths:
  /v1/oauth/device/token:
    post:
      tags:
        - OAuth
      summary: Poll a device-flow for completion (RFC 8628 §3.4)
      description: >-
        **Use when:** caller (typically a CLI) is polling for the user to
        approve the device-code flow it started — returns the access_token +
        refresh_token once approved, or a structured error code
        (authorization_pending / slow_down / expired_token / access_denied)
        while still pending


        Per RFC 8628, errors during the polling phase use a 400 status with a
        stable `error` code the CLI branches on: `authorization_pending` (keep
        polling), `slow_down` (back off), `expired_token` (start a new flow),
        `access_denied` (user clicked Deny). Successful approval returns 200
        with the issued token pair.
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              properties:
                grant_type:
                  type: string
                  enum:
                    - urn:ietf:params:oauth:grant-type:device_code
                device_code:
                  type: string
                  minLength: 1
              required:
                - grant_type
                - device_code
      responses:
        '200':
          description: Access + refresh token pair issued.
        '400':
          description: >-
            Polling error — `authorization_pending` / `slow_down` /
            `expired_token` / `access_denied`.
        '401':
          description: Missing or invalid Bearer credentials
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/ErrorResponse'
        '500':
          description: Internal server error
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/ErrorResponse'
      security:
        - bearerAuth: []
components:
  schemas:
    ErrorResponse:
      type: object
      properties:
        error:
          type: string
          description: Stable error code (e.g. `invalid_request`)
        message:
          type: string
          description: Human-readable error message
        details: {}
      required:
        - error
        - message
  securitySchemes:
    bearerAuth:
      type: http
      scheme: bearer
      bearerFormat: API Key
      description: >-
        Verlon API key (newly minted keys are prefixed `sk-vrln-`; legacy
        `verlon_*` and `layer_*` keys from prior prefix migrations continue to
        validate). Generated from the dashboard under Settings → API Keys, or
        via `verlon key create` in the CLI.

````