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
2.0 KiB
method, path, auth, area
| method | path | auth | area |
|---|---|---|---|
| POST | /api/devices/register/status | none | devices |
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)
{
"registration_id": "registration-uuid"
}
Response (200 OK)
{
"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).