REST Launcherは、Flowを通常のHTTPエンドポイントに変換します。デプロイされた各Flowは単一のルート POST /flows/:name/runs として公開され、すべての呼び出しは Run、つまり実行された正確なdigestで識別されるFlowSpecの1回の実行記録を返します。実行時にモデルは介在しません。呼び出し側がFlowを呼び出すことを決め、Flow自体は他のすべてのLauncherを支える同じRiderの下で決定論的に実行されます。 このタブのエンドポイントページはOpenAPI specから生成されています。このページでは、APIサーフェス全体について、どこで提供されるか、実行ライフサイクル、返される形を説明します。
このAPIリファレンスには、Browserflow（オープンソースエンジン）とJinba Trail（その上に構築されたホスト型プロダクト）が別の製品であるため、異なる2つのspecに基づく2つの側面があります。
  • このページと以下のルートは、OSS REST Launcher（browserflow serve）とセルフホストのコントロールプレーン（@browserflow/web-api）を説明します。これらは openapi.json から生成されています。組織、APIキー、テナンシーはありません。ここでのBearerトークンは、自分でプロビジョニングするコントロールプレーンのRBACトークンです。
  • ホスト型のJinba Trailプロダクト、つまり組織、Bearer jbt_live_*/jbt_test_* APIキー、公開実行ゲートウェイ（POST /v1/run/:flow）、ホスト型MCPエンドポイント（POST /mcp）、Build studio、実行、スケジュール、メンバー、監査は、別のspecである openapi.jinbatrail.json です。api.jinbatrail.indx.jp を呼び出している場合、またはJinba Trailダッシュボードを対象に構築している場合は、このspecではなくそのspecが信頼できる情報源です。プロダクトレベルのウォークスルーは Playground & API keys と Connect via MCP を参照してください。
どちらのspecも同じ基盤の決定論的エンジンを説明しています。Jinba Trailの /v1/run/:flow も、同じRiderの下でFlowSpecを実行します。ただし、そのラッパーは、素のOSSサーフェスには存在しないテナンシー、認証、プロダクトオブジェクト（Automation/Version/Endpoint）を追加します。

​
APIが提供される場所

RESTサーフェスがオンラインになる方法は2つあり、どちらも同じルートを話します。
サーバースタック用途
browserflow serveBun上のHonoローカルまたはマウントされたRegistryから、インフラなしでFlowをHTTPエンドポイントとして立ち上げます
@browserflow/web-api control planeBun上のHono、SQLite PlaneStoreRegistry、実行、デプロイ、スケジュール、シークレットのルートを備えたチーム向けデプロイ
スタンドアロンでは、Registryを指定し、ポートを選んでサーバーを起動します。 
browserflow serve --registry ./registry --port 8080
# POST /flows/daily-price-watch/runs   { "query": "..." }  → Run
ベースURLはデフォルトでポート :8080 です。コントロールプレーンは自身のAPIホスト（たとえば https://plane.acme.dev）の背後で同じルート形状を提供するため、browserflow serve に対して書かれたクライアントは、変更なしでプレーンに対しても動作します。
ルート、Run スキーマ、状態値は、実装済みの @browserflow/web-api パッケージから直接来ています。全体の文脈は launchers と domain model のドキュメントで説明しています。

​
Flowごとに1つのルート

FlowがRESTにデプロイされると、正確に1つのエンドポイントになります。 
POST /flows/:name/runs
標準的な daily-price-watch Flow、つまりブラウザTool（search-price@1.2.0）→ transform → シークレットのwebhookへの条件付き http.post を使う場合、デプロイされたルートは POST /flows/daily-price-watch/runs です。リクエストボディは、Flowの型付き入力を名前で運びます。 
curl -X POST http://localhost:8080/flows/daily-price-watch/runs \
  -H "Content-Type: application/json" \
  -d '{ "query": "wireless headphones" }'
Riderが何かを実行する前に、ボディはFlowで宣言された inputs contractに対して検証されます。Flowは宣言的にRESTへデプロイされます。 
browserflow deploy daily-price-watch --as rest
デプロイは、RESTフロントでどの Flow digest がliveかを記録するため、ロールバックは以前のdigestへ向け直すことです。再ビルドではありません。

​
実行ライフサイクル

実行は、Flowの runs ルートへ POST することで開始されます。レスポンスは、同期Flowでは Run、長時間実行されるFlowではポーリング対象のrun idです。同期にするかfire-and-pollにするかは、ルートごとに選べます。
1

実行を開始する

型付き入力とともに POST /flows/daily-price-watch/runs を呼び出します。Riderはボディを検証し、digestで固定されたFlowSpecを解決して、実行を開始します。
2

Runまたはrun idを受け取る

同期ルートは完了した Run を直接返します。fire-and-pollルートは、status が pending または running のRunを返し、ポーリングに使う id を含みます。
3

実行をポーリングする

長いFlowでは、status が終端値（succeeded、failed、または canceled）に達するまで、id でRunを取得します。返されるRunは journal を持ち、成功時には output も持ちます。
4

Journalを読む

journal は、手順ライフサイクルイベントの追記専用で順序付きのログです。CLIとrun inspectorが読むものと同じJournalです。第二の信頼できる情報源はありません。
Run とその Journal がレスポンス契約のすべてです。実行がインラインで完了した場合でも、ポーリングして取得した場合でも、すべてのルートは同じ形を返します。

​
レスポンス形状

​
Run

すべてのエンドポイントは Run を返します（または、長いFlowが実行中の場合は、status がまだ終端ではない Run を返します）。これは domain model からの正規スキーマです。 
export const RunSchema = z
  .object({
    id: z.string().min(1),              // uuidv4
    flow_digest: z.string().min(1),     // 実行された正確なFlowSpec
    status: z.enum(["pending", "running", "succeeded", "failed", "canceled"]),
    started_at: z.string(),             // ISO-8601
    finished_at: z.string().optional(),
    journal: z.array(JournalEntrySchema),
    output: z.unknown().optional(),
  })
  .strict();
フィールド型意味
idstring (uuidv4)run identifier。長いFlowではこれをポーリングします
flow_digeststring実行された正確なFlowSpecの sha256 digest
statusenumpending、running、succeeded、failed、または canceled
started_atstring (ISO-8601)実行が開始した時刻
finished_atstring (ISO-8601), optional実行が終端状態に達した時刻
journalJournalEntry[]手順ライフサイクルイベントの追記専用で順序付きのログ
outputunknown, optionalFlowの型付き出力projection。成功時に存在します
flow_digest が正確で不変のFlowSpecを固定するため、Runは自己記述的です。どのフロントが呼び出したかに関係なく、どのバージョンのFlowが結果を生成したかを正確に示します。

​
Journal

journal はレスポンスの中心です。開始、出力、失敗、リトライ、スキップといった手順ライフサイクルイベントに、解決済み入力と最終出力を加えた、追記専用で順序付きのログです。daily-price-watch では、journalは search-price@1.2.0 ブラウザ手順、transform、条件付き http.post が実行されたかどうかを記録します。同じJournalにより、実行は再開可能（完了済み手順を再実行せずにリプレイ）かつ検査可能（CLIまたはUIで実行をタイムトラベル）になります。
コントロールプレーンのrun inspectorは、この正確なJournalを読みます。「UIで見えるもの」と「browserflow inspect が出力するもの」は同じデータです。observability を参照してください。

​
認証とシークレット

認証と認可は、エンジンではなくコントロールプレーンによって仲介されます。RBACロールは、誰がFlowを実行でき、誰が実行とそのjournalを読み取れるかをスコープします。すべての特権操作（実行を含む）は、content-addressedな監査ログに記録されます。access control を参照してください。
シークレットの値はいかなるレスポンスでも返されません。daily-price-watch のwebhook URLのような secret: true 入力は、参照としてのみ運ばれ、実行時に、secrets capabilityを宣言する1つの手順内で、worker上で解決されます。それはFlowSpec、Journal、ログ行、APIレスポンスのいずれにも現れず、run inspectorはロールに関係なくそれをマスクします。secrets を参照してください。

​
関連

REST APIをデプロイする

Packを公開し、daily-price-watch をRESTフロントでエンドツーエンドに公開します。

Launcher

RESTがCLI、MCP、cron、embeddedとどのように並ぶか。1つのFlowSpec、多数のフロント。

アクセス制御

誰がFlowを実行し、そのjournalを読めるかを制御するRBAC、監査、テナンシー。

シークレット

境界の不変条件。なぜシークレット値が実行から外に出ないのか。