John O'Keefe
ae9588f1c6
Beam backfilled auth core (login/register/refresh/logout/profile) and devices
core (list/update/delete/shelf CRUD/sidecar/register flow) with frontmatter,
provenance, and labeled examples. All claimed shapes verified against
handlers: AuthResponse {access_token, refresh_token omitempty, token_type,
expires_in, user}, update device {device_updated, device}, shelf wrappers,
DeviceAuthStatusResponse.
Claude registry verification: 15 entries pinned by type (LoginRequest,
RegisterRequest, AuthResponse, RefreshTokenRequest/Response, UserProfile,
DeviceListResponse, DeviceUpdateRequest, AddToShelfRequest, SidecarConfig,
DeviceRegistrationRequest/Response, DeviceAuthStatusRequest/Response).
Removed revoke_device.md — name-only duplicate of delete_device.md (same
DELETE /api/devices/:id route; was the last audit-orphan doc).
Gate catches this round (subtle Go serialization facts, now pinned in docs):
- uuid.UUID arrays never serialize as omitted: register/status response
ALWAYS carries device_id (all-zeros while pending) despite omitempty
- update device request binds device_name, not name
- register response includes device_id alongside registration_id
- list devices response is a {devices, total} wrapper
57 lines
2.0 KiB
Markdown
57 lines
2.0 KiB
Markdown
---
|
|
method: POST
|
|
path: /api/devices/register/status
|
|
auth: none
|
|
area: devices
|
|
---
|
|
<!-- source: internal/handlers/devices.go:178 DeviceHandler.CheckRegistrationStatus -->
|
|
|
|
# Get Device / Check Registration Status
|
|
|
|
Check device registration status or get device details.
|
|
|
|
**Endpoint**: `POST /api/devices/register/status` or `GET /api/devices/{device_id}`
|
|
**Auth**: Not required for status check, Required for device details
|
|
**Content-Type**: `application/json` (for status check)
|
|
|
|
## Request Body (Status Check)
|
|
|
|
| Field | Type | Required | Description |
|
|
| --------------- | ------ | -------- | ----------------- |
|
|
| registration_id | string | Yes | Registration UUID |
|
|
|
|
### Example Request (Status Check)
|
|
|
|
```json example-request
|
|
{
|
|
"registration_id": "registration-uuid"
|
|
}
|
|
```
|
|
|
|
## Response (200 OK)
|
|
|
|
```json example-response
|
|
{
|
|
"status": "pending",
|
|
"device_id": "00000000-0000-0000-0000-000000000000"
|
|
}
|
|
```
|
|
|
|
`device_id` is always present (a uuid.UUID array never serializes as omitted —
|
|
it reads as all-zeros while pending). `status` is `pending` or `approved`.
|
|
While pending, the response includes `message` and `expires_in` (seconds
|
|
remaining). Once approved, the response includes `auth_token`, `device_id`,
|
|
and `sync_endpoints`; `auth_token` fields are empty when pending.
|
|
|
|
**The approved response is single-use**: the registration is deleted from the pending map once returned, so store the `auth_token` immediately. A repeat status check for the same `registration_id` returns 404.
|
|
|
|
## Error Responses
|
|
|
|
| Code | Description |
|
|
| ---- | -------------------------------------------------- |
|
|
| 400 | Invalid or missing `registration_id` |
|
|
| 404 | Registration not found (unknown or already issued) |
|
|
| 410 | Registration expired (`{"error": "registration expired"}`) |
|
|
|
|
Note: expiration is signaled by HTTP 410 Gone, not a `"status": "expired"` value. Pending registrations are held in server memory, so a server restart also invalidates them (subsequent checks return 404).
|