
Why Codia exposes APIs
Codia products convert visual content into editable, structured assets. The API exists for teams that want the same capability inside their own product, migration script, agent workflow, QA system, or design automation pipeline.
The developer platform is centered on a simple idea: visual inputs should become structured data that software can reason about.
Visual Struct for images
The Visual Struct image endpoint converts a UI screenshot or mockup into a hierarchical JSON tree.
POST https://api.codia.ai/v1/open/image_to_designThe response includes typed elements such as headers, buttons, cards, tables, charts, icons, text, and panels. Nodes include bounding boxes, layout configuration, confidence metadata, and child elements.
The docs describe three output formats:
jsonfor custom downstream pipelinessvgfor a design-tool-agnostic vector re-renderfigmafor insertion into a Figma file through a plugin or import flow
This is the API to use when a screenshot, UI mockup, or visual reference needs to become machine-readable.
PDF to Visual Struct
PDFs use a related endpoint:
POST https://api.codia.ai/v1/open/pdf_to_designThe endpoint converts a PDF page into Codia's Visual Element Schema: a typed hierarchy with bounding boxes, layout configs, style specs, and child elements. The same schema shape is shared with image Visual Struct, so downstream consumers can support both image and PDF inputs with one processing model.
The docs list common uses such as Figma importers, code generators, visual QA pipelines, and rendering workflows.
Uploads and task workflows
For workflows that need private file handling or long-running jobs, existing Open API content describes an upload and task pattern:
- upload a private file to
/v1/open/uploads - receive an opaque
upload_id - create a task through
/v1/open/tasks - receive webhook events or poll task status
- download the generated output when the task completes
The NotebookLM-style PDF to editable PPTX article uses this pattern for server-side PDF-to-PowerPoint automation. The key implementation rule is that the Codia API key stays on your server, not in the browser.
What developers build with it
The API is useful when a team needs structured visual understanding inside another system:
- competitive UI archiving and analysis
- design-system audits
- automated visual QA and regression checks
- screenshot-to-Figma import flows
- PDF-to-schema extraction
- code generation preprocessing
- agent workflows that need machine-readable UI structure
- batch migration tools for large design archives
The output is not just a screenshot with labels. It is a tree that can be filtered, transformed, rendered, imported, or passed into another model.
Integration boundaries
The public docs are clear about a few practical boundaries:
- API calls require bearer-token authentication.
- Credit checks happen before some uploads are read.
- Output quality depends on source clarity and layout complexity.
- Tall screenshots may work better when chunked at section boundaries.
- Low-confidence nodes should be filtered before downstream use.
- Enterprise deployments can review retention, production usage, higher rate limits, and private deployment needs.
Those boundaries are part of the developer experience. A reliable API should make its tradeoffs visible.
Where to start
Start with Visual Struct for screenshots and mockups. Use PDF to Visual Struct for PDFs. Open the API Reference for endpoint schemas and request/response fields.