Site Plan & CAD Handoff — Developer Docs
Read Site Plan Studio design data and export concept geometry for Civil 3D.
How do I read site-plan design data and export concept geometry?
All four endpoints require the siteplan:read scope. Every key and connector token carries the full scope set by default, so no separate grant step exists.
| Endpoint | What it does | Rate limit |
|---|---|---|
GET /v1/projects/{project_id}/site-plan | Latest compiled concept as a WGS84-only GeoJSON FeatureCollection, plus metrics and scenario | 60/min |
GET /v1/projects/{project_id}/design-criteria | Resolved zoning standards per district with per-field provenance | 60/min |
GET /v1/projects/{project_id}/yield-scenario | Settled yield scenarios per district plus snapshot summaries | 60/min |
POST /v1/projects/{project_id}/site-plan-exports | Renders the concept to LandXML, DXF, or GeoJSON and returns a signed download URL | 10/min |
Concept geometry: until a concept compiles in Site Plan Studio, the site-plan route returns has_concept: false with an empty feature collection. Features carry object_type, label, layer, status, editable, and measurements; projected coordinates are stripped, WGS84 only. measurements holds site numbers only - solver bookkeeping (planner strategy, fit ratios, discarded-geometry counters) is excluded, so nothing there should be read as an area or dimension on the ground.
Design criteria: absent values are never bare nulls. A field reads Not provided in ordinance only when the extraction corroborated the absence; otherwise it reads Not located in the indexed ordinance, which claims nothing about the law. user_provided_fields lists the values the user themselves confirmed. citations are readable references such as Tangipahoa Parish Code § 36-91; retrieval chunk identifiers are never returned as citations. stormwater_context splits into known and not_in_code, so a requirement the code is silent on is named rather than read as a zero. governing_district is the district the concept is compiled and checked against, with its basis (current, or rezone_target once the user confirmed a rezone in Site Plan Studio) and the parcel district as current_zoning_code beside it; a rezone target is also listed in districts, so never take the parcel district for the governing one.
Yield scenarios: values the user settled under one district are inherited into another district's partition when missing, with the borrowing stated per key in inherited.
CAD handoff: landxml is the native Civil 3D import format; dxf covers generic CAD. The response is artifact_id, filename, mime_type, download_url, and expires_at (15 minutes); geometry travels as a file, never inline. Send an Idempotency-Key header so a retried request replays the original artifact. With no compiled concept the endpoint returns 404 (no_site_plan_concept).
How do I walk the guided site-planning interview from my own agent?
Three endpoints walk the same interview the PrecisionDocs app walks. The engine is deterministic: it picks the next question and already knows what the project settled, so you never decide what to ask next.
| Endpoint | What it does | Rate limit |
|---|---|---|
GET /v1/projects/{project_id}/interview/workflows | Guided workflows this project can walk, which one it is on, and how far in (siteplan:read) | 60/min |
GET /v1/projects/{project_id}/interview/step | The next 1-3 questions as JSON Schema, plus what is already answered or inferred (siteplan:read) | 60/min |
POST /v1/projects/{project_id}/interview/answers | Submit typed answers, get the next step back (project:create) | 30/min |
Both reads are free. No LLM call and no credit spend, so poll them rather than guessing what comes next. Only the answer endpoint writes.
Questions arrive as JSON Schema mapped from the same control the in-app card renders: types, ranges, units, and options with their labels. A default on a field is the engine's recommendation, and recommended.reason says why - offer it as a suggestion, never as a requirement.
Nothing is asked twice. answered lists what the project settled and inferred lists what the engine derived, each with the statement behind it. remaining_question_ids is the rest of the walk; complete: true with no questions means the scripted interview is finished, and completeness.missing_required names anything a concept still needs.
A rejected batch records nothing. Values are validated against the same schema server-side; a 400 invalid_interview_answer names every bad field under detail.errors, so fix those and resend the same batch. What is recorded is the user's own decision, on the same ledger the in-app card writes - so an interview can be started in the app and finished over the API, or the other way round.
Read standing, not the workflow rows. standing always describes the walk the project is on. selected_workflow_id is null both before a workflow is chosen and for a use that has no template lane (commercial, hotel), so a null there never means the interview has not started.