---
title: "Get Drawing"
method: GET
path: "/api/v1/drawings/{drawing_id}"
tags: ["drawings"]
---

# Get Drawing

`GET /api/v1/drawings/{drawing_id}`

## Path parameters

- `drawing_id` string, uuid, required

## Response `200`

Successful Response

- DrawingDetail — Extends Drawing with the latest extraction's status and error, for polling and failed-state retry UX. `current_extraction_status` is `None` if no extraction has been enqueued yet (e.g., drawing record created but `/ingest` not called). `current_extraction_error` is `None` unless the latest extraction is `failed`, in which case it carries the parser error string. `current_sheets_status` tracks the latest Step-3 sheet-naming run (ADR-0060), which fans out in parallel with text analysis and finishes AFTER ingest completes. The FE polls while it is non-terminal and refetches pages when it flips to `completed` (names arrive after `current_extraction_status`). `sheets_named_count` counts pages with a checkpointed naming read in the latest sheets run (`metadata->'checkpoint'->'naming'` keys). It resumes across redeliveries and resets to 0 when a new run starts. `page_count` is the drawing's current page-row count. The ingest pill consumes both for "Naming sheets X/X". `current_extraction_is_stale` is True when the latest extraction is in-flight (`pending`/`running`) and its attempt clock (`started_at`) is older than the API's staleness horizon — the FE renders the stale-ingest retry affordance on it (RUD-152). Server-computed; the FE never re-derives it. `scale_applied_result_count` counts autoset apply receipts (`page_scale_results.applied = true`) on the drawing's current pages. Within a stable extraction era it is a level-triggered revision signal: the web client refreshes its pages cache whenever the value changes (a backfill promotion or live apply materialized a scale). Across a re-ingest the era resets and the existing pending-count >0->0 transition owns the refresh instead. `scale_pending_page_count` only drives poll cadence. Scale-verifier v2 Plan 5 design §2. `current_extraction_analyzed` is True once Stage-2 analysis stamped `pdf_extractions.analyzed_at` on the latest extraction. It exists to disambiguate `scale_pending_page_count == 0`, which the pending count alone cannot do: the count joins on `analyzed_at IS NOT NULL`, so it reads 0 both before autoset has any job in flight and after every page reached a terminal result. False + 0 means "not enqueued yet" (Stage-2 is still running, possibly behind a larger drawing on the single analyze_pdf consumer); True + 0 means "autoset ran and every page is settled". Read-only diagnostic — it does not change what the pending count means or the cadence it drives (RUD-480).
  - `id` string, uuid, required
  - `project_id` string, uuid, required
  - `name` string, required
  - `created_at` string, date-time, required
  - `current_extraction_status` 'pending' | 'running' | 'completed' | 'failed', nullable
  - `current_sheets_status` 'pending' | 'running' | 'completed' | 'failed', nullable
  - `current_extraction_error` string, nullable
  - `sheets_named_count` integer
  - `page_count` integer
  - `scale_pending_page_count` integer
  - `scale_applied_result_count` integer
  - `current_extraction_is_stale` boolean
  - `current_extraction_analyzed` boolean

## Other responses

- `4XX` — Client Error
- `5XX` — Server Error

---

[API](https://skmtc.dev/rudus/apis/rudus-api.md) · [All operations](https://skmtc.dev/rudus/apis/rudus-api/llms.txt) · [OpenAPI document](https://skmtc-service-production.skmtc.workers.dev/v1/apis/rudus/rudus-api/revisions/f149124a4d80/schema)