なぜCodiaはAPIを公開するのか
Codiaの製品は、ビジュアルコンテンツを編集可能で構造化された資産へ変換します。APIは、その能力を自社製品、移行スクリプト、エージェントワークフロー、QAシステム、デザイン自動化パイプラインの中に組み込みたいチーム向けです。
開発者プラットフォームの中心にある考え方はシンプルです。ビジュアル入力は、ソフトウェアが推論できる構造化データになるべきだということです。
画像向けVisual Struct
Visual Structの画像エンドポイントは、UIスクリーンショットやモックアップを階層的なJSONツリーへ変換します。
POST https://api.codia.ai/v1/open/image_to_designレスポンスには、header、button、card、table、chart、icon、text、panelのような型付き要素が含まれます。ノードにはバウンディングボックス、レイアウト設定、信頼度メタデータ、子要素が含まれます。
ドキュメントでは3つの出力形式が説明されています。
jsonはカスタムの下流パイプライン向けsvgはデザインツールに依存しないベクター再描画向けfigmaはプラグインまたはインポートフロー経由でFigmaファイルへ挿入するためのもの
スクリーンショット、UIモックアップ、視覚参考資料を機械可読にしたいときに使うAPIです。
PDF to Visual Struct
PDFには関連エンドポイントがあります。
POST https://api.codia.ai/v1/open/pdf_to_designこのエンドポイントは、PDFページをCodiaのVisual Element Schemaへ変換します。バウンディングボックス、レイアウト設定、スタイル仕様、子要素を含む型付き階層です。画像Visual Structと同じschema形状を共有するため、下流システムは1つの処理モデルで画像とPDFの両方に対応できます。
ドキュメントでは、Figmaインポーター、コード生成、ビジュアルQAパイプライン、レンダリングワークフローなどの用途が挙げられています。
アップロードとタスクワークフロー
プライベートファイル処理や長時間ジョブが必要なワークフローでは、既存のOpen APIコンテンツがアップロード＋タスクのパターンを説明しています。
- 私有ファイルを
/v1/open/uploadsにアップロードする - 不透明な
upload_idを受け取る /v1/open/tasksでタスクを作成する- webhookイベントを受け取るか、タスク状態をポーリングする
- タスク完了後に生成物をダウンロードする
NotebookLM-style PDF to editable PPTXの記事では、このパターンを使ってサーバーサイドのPDF-to-PowerPoint自動化を行っています。重要な実装ルールは、CodiaのAPI keyをブラウザではなくサーバー側に置くことです。
開発者は何を作るのか
このAPIは、チームが構造化されたビジュアル理解を別のシステムへ組み込みたいときに役立ちます。
- 競合UIのアーカイブと分析
- デザインシステム監査
- 自動化されたビジュアルQAと回帰チェック
- Screenshot to Figmaのインポートフロー
- PDF-to-schema抽出
- コード生成前処理
- 機械可読なUI構造を必要とするエージェントワークフロー
- 大規模デザインアーカイブ向けの一括移行ツール
出力は単なるラベル付きスクリーンショットではありません。フィルタ、変換、描画、インポート、あるいは別モデルへの受け渡しができるツリーです。
統合の境界
公開ドキュメントはいくつかの実務的な境界を明確にしています。
- API呼び出しにはBearerトークン認証が必要
- 一部のアップロードは読み込み前にcreditsを確認する
- 出力品質はソースの明瞭さとレイアウトの複雑さに依存する
- 縦長スクリーンショットは、セクション境界で分割すると扱いやすい
- 下流で使う前に、信頼度の低いノードを除外するべき
- エンタープライズ導入では、保持、商用利用、より高いレート制限、プライベート導入要件をレビューできる
こうした境界も開発者体験の一部です。信頼できるAPIは、自分のトレードオフを見える形にすべきです。
どこから始めるか
スクリーンショットとモックアップは Visual Struct から始めてください。PDFは PDF to Visual Struct を使ってください。エンドポイントのschemaとrequest/responseフィールドは API Reference を参照してください。