POST /v1/ai/site-builds/{siteBuildId}/plugin-plan

認証

ベアラー トークンとして API キーを送信します。キーには sites.create 権限が付与されている必要があります。権限のないキーは 404 ではなく 403 で拒否されます。

このエンドポイントは組織IDを受け付けません。お使いのキーによって所属する組織がすでに特定されており、レスポンスはその組織にスコープされます。

試してみる

アングルブラケット内のすべてをご自身の値に置き換え、キーのプレースホルダーをご利用中のダッシュボードのキーに置き換えてください。

curl -X POST https://api.zinndigital.com/v1/ai/site-builds/{siteBuildId}/plugin-plan \
  -H "Authorization: Bearer zdk_live_…"

ログインしていますか？ダッシュボード内のAPIコンソールでは、実際の組織IDやお客様ご自身のキーが自動入力され、ライブAPIに対してリクエストが実行されるため、実際のレスポンスを確認することができます。 API コンソールでこのエンドポイントを開く

詳細

Chooses plugins for the generated site from a curated set, and writes one small WordPress plugin when the site needs behaviour no listed plugin provides. Generated PHP is scanned before it is packaged, not before it is installed: dynamic execution, shell access, remote includes, direct filesystem writes, unescaped request data and hand-built SQL are refused outright, and a plugin that fails never becomes an archive at all. When that happens the reason appears in notes — a scan that silently dropped its subject would be indistinguishable from a scan that found nothing. Slugs the model proposes that are not in the curated set are dropped and counted in rejected rather than passed through. The generated plugin's source is deliberately not returned. It is real PHP that has passed the scan; handing it to a client invites an edited copy to be posted back on a path that believes it was scanned. Ask for it at publish time with include_generated_plugin, and it is regenerated and re-scanned there. Spends AI credit and is metered under the site_builder surface, on the one AI meter. Requires sites.create.

パラメータ

返信

このエンドポイントが返すエラー

401 · 403 · 404 · 422 · 429