POST /v1/sites/{siteId}/panel-sessions

認証

ベアラー トークンとして API キーを送信します。このエンドポイントでは仕様に特定の権限が記載されていないため、キーに必要な最小限の権限を付与し、推測するのではなくレスポンスを確認してください。

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

試してみる

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

curl -X POST https://api.zinndigital.com/v1/sites/{siteId}/panel-sessions \
  -H "Authorization: Bearer zdk_live_…" \
  -H "Content-Type: application/json" \
  -d '{ "tool": <string<phpmyadmin, filemanager, web_ide>> }'

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

詳細

Returns a freshly minted single-use SSO link into **one** of the site's per-site tools — phpMyAdmin or the File Manager — for the caller to open immediately. **Why this exists rather than reusing `getSiteDatabase`.** The links that endpoint returns are single-use and expire in **180 seconds**, deliberately: a panel link that still works tomorrow is a credential. Rendering one into an `<a href>` on page load therefore hands the customer something that is dead before they have read the card — they click four minutes later and are told the token expired, which reads to them as being asked to log in. This endpoint moves the mint to the click, so the token's whole life is one redirect. Same authority as `getSiteDatabase`: **both** `sites.view` and `sites.panel_access`, RLS-scoped on the narrower key, so holding `sites.panel_access` in one org can never mint a link for another org's site. An out-of-scope or unknown id is a `404`, never a `403`, so this cannot be used to discover that a site exists. `POST` because it is **not idempotent**: every call writes a new single-use token to the hosting box. A `GET` would be re-issued by a prefetch, a proxy or the back button, burning a token each time. A site with no panel to open is a `409` carrying the same sentence the Tools card shows — never a `200` with a null URL.

パラメータ

リクエスト本文

返信

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

401 · 403 · 404 · 409 · 422 · 429