---
title: "Describe a pending device authorization for the approval page (T832)"
method: GET
path: "/auth/device/info"
tags: ["Auth"]
---

# Describe a pending device authorization for the approval page (T832)

`GET /auth/device/info`

## Request

- Base URL: `http://localhost:38200`
- URL: `http://localhost:38200/auth/device/info`
- Auth: none required

Public, rate limited. Backs the `/link` approval screen: given the `user_code` shown on the device, returns what the human needs in order to decide -- which client asked, from which host, which scopes, and when the code expires. Carries NO secret: no device code, no API key, no tenant. `client_name` and `hostname` are client-supplied claims that identify the request; they do not authorise it.
Unauthenticated for the same reason approve/deny are (see `denyDeviceAuthorization`'s note): a pending row has no tenant yet, and the code on the device's screen IS the authorization boundary, per RFC 8628. An EXPIRED pending grant is reported as `status: expired` rather than 404, because the page has to tell a human who waited too long what actually happened.

## Query parameters

- `user_code` string, required

## Response `200`

The grant's display state.

- object
  - `status` 'pending' | 'approved' | 'denied' | 'expired'
  - `clientName` string, nullable: Client-supplied claim. Null when the client did not state one.
  - `clientHostname` string, nullable: Client-supplied claim. Null when the client did not state one.
  - `scopes` string[]: Scopes the minted key would carry.
  - `expiresAt` string, date-time

## Other responses

- `400`: Missing or malformed user_code.
- `404`: No grant matches that code.

---

[API](https://skmtc.dev/contextq/apis/contextq-api.md) · [All operations](https://skmtc.dev/contextq/apis/contextq-api/llms.txt) · [OpenAPI document](https://skmtc.dev/contextq/apis/contextq-api/revisions/7afc44056a22?raw)