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

> ## Agent Instructions
> Every Lath operation is POST https://platform.trylath.com/<operation name with dots replaced by slashes>, with a JSON body and `Authorization: Bearer <key>`. `email.send` is POST /email/send.
> Branch on `error.code`, never on `error.message`. Every refusal also carries `error.fix`, which names the next step.
> Send an `Idempotency-Key` header on any operation that is not retry-safe, so a retry cannot run it twice.
> A `lath_test_` key emails only the account's own members and sends no SMS; a `lath_live_` key reaches real recipients and is billed.
> The OpenAPI document, generated from the same registry as the routes, is at https://platform.trylath.com/openapi.json.

# auth.device.approve

> Approves or denies a device sign-in by user code, on behalf of a signed-in person. The person's access token proves who is approving; the device then receives a session for that user on its next poll. Approving needs a recent sign-in, and a session that passed the second factor when the account has one, because it hands a session for the account to another machine. Denying needs neither: someone who did not start this sign-in should be able to stop it at once. Callable with a publishable key (the hosted approval page) or a secret key (your app's own approval screen).



## OpenAPI

````yaml /api-reference/openapi.json post /auth/device/approve
openapi: 3.1.0
info:
  title: Lath API
  version: 0.1.0
  description: >-
    Every operation is one POST. The same set is reachable over MCP, the SDK and
    the CLI; nothing is dashboard-only.
servers:
  - url: https://platform.trylath.com
    description: This deployment
security: []
paths:
  /auth/device/approve:
    post:
      tags:
        - auth
      summary: auth.device.approve
      description: >-
        Approves or denies a device sign-in by user code, on behalf of a
        signed-in person. The person's access token proves who is approving; the
        device then receives a session for that user on its next poll. Approving
        needs a recent sign-in, and a session that passed the second factor when
        the account has one, because it hands a session for the account to
        another machine. Denying needs neither: someone who did not start this
        sign-in should be able to stop it at once. Callable with a publishable
        key (the hosted approval page) or a secret key (your app's own approval
        screen).
      operationId: auth.device.approve
      parameters:
        - name: Idempotency-Key
          in: header
          required: false
          schema:
            type: string
          description: >-
            Replays the stored response for the same key and input; refuses
            different input.
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $schema: https://json-schema.org/draft/2020-12/schema
              type: object
              properties:
                userCode:
                  type: string
                  minLength: 8
                  maxLength: 9
                  description: The code the device displayed, like BDWP-HQPK
                accessToken:
                  type: string
                  minLength: 20
                  description: The approving person's current access token
                decision:
                  default: approve
                  type: string
                  enum:
                    - approve
                    - deny
              required:
                - userCode
                - accessToken
              additionalProperties: false
      responses:
        '200':
          description: '{ activityId, result }. activityId is empty for reads.'
          content:
            application/json:
              schema:
                type: object
                properties:
                  activityId:
                    type: string
                    description: The activity this call created, or empty for a read.
                  result:
                    $schema: https://json-schema.org/draft/2020-12/schema
                    type: object
                    properties:
                      userCode:
                        type: string
                      decision:
                        type: string
                        enum:
                          - approve
                          - deny
                      clientName:
                        type:
                          - string
                          - 'null'
                    required:
                      - userCode
                      - decision
                      - clientName
                    additionalProperties: {}
                required:
                  - activityId
                  - result
        '400':
          description: invalid_input or invalid_json
        '401':
          description: unauthenticated
        '403':
          description: forbidden
        '404':
          description: not_found
        '409':
          description: 'conflict: idempotency_mismatch, email_taken, last_key'
        '413':
          description: body_too_large
        '429':
          description: rate_limited
      security:
        - bearer: []
components:
  securitySchemes:
    bearer:
      type: http
      scheme: bearer
      description: >-
        A Lath API key: lath_live_sk… or lath_test_sk… on a server,
        lath_live_pk… or lath_test_pk… in a browser.

````