Codia
Back to all posts

Open API and the Codia Developer Ecosystem

Developer Platform2026-04-22

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.

http
POST https://api.codia.ai/v1/open/image_to_design

The 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:

  • json for custom downstream pipelines
  • svg for a design-tool-agnostic vector re-render
  • figma for 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:

http
POST https://api.codia.ai/v1/open/pdf_to_design

The 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.

#open-api#visual-struct#developer-api#json#automation