salla-app-ui-builder

Salla App Store の掲載ページ（app_page_builder）

掲載ページは、App Store 上およびアプリのインストール時にマーチャントに表示される、アプリのホーム／ランディングページです。掲載ページは、順序付きのブロックリスト（App Information、Features、Reviews、Brands、FAQ、Stats。init／catalog によって動的に表示されます）で構成され、すべて app_page_builder MCP ツールを通じて作成します。REST エンドポイントや扱うトークンはありません。掲載ページの作業は app_page_builder と salla_upload を通じて行ってください。

ブロックの要素の値を編集すると、共有の掲載コンテンツがアプリのドラフト公開に直接書き込まれます。このツールが管理するフィールドは、name、description、logo、screenshots、benefits です（値の形式については、blocks-and-fields.md を参照してください）。

short_description は別の場所にあります。公開の basic_information セクションにあり（50～200 文字）、app_publish → salla-publication-consistency を通じて書き込みます。ここではなく、そちらで作成してください。

前提条件：まずドラフトを開く

app_page_builder は、アプリが公開され、ドラフト公開がある場合に使用できます。まずドラフトを作成してください。

app_publish action=open

公開／ドラフトのライフサイクル（公開を開始し、公開セクションに入力し、ドラフトを検証して保存した後、パートナーがポータルで送信します）は salla-publication-consistency が管理します。全体の流れについては、そのスキルを参照してください。ドラフトが作成されると、app_page_builder は共有の掲載コンテンツをそこに書き込みます。

9 つのアクション

すべての呼び出しでは action=（および MCP がすでに保持しているアプリコンテキスト）を指定します。書き込みの前に、読み取りアクション（catalog、list、show）で形式を確認してください。

一般的な流れ： app_publish action=open → app_page_builder action=init（必須ブロックを用意）→ action=list → action=show（各ブロックの要素キーを確認）→ action=set（値を書き込み）→ 必要に応じて action=add／remove／sort。

パラメーター、戻り値、エラーを含むアクションの仕様全体は、api-spec.md に記載されています。

メディア（ロゴ、スクリーンショット）

画像要素（logo、screenshots）は、アップロードしたメディア ID を参照します。

1. source_url を指定して salla_upload を呼び出すと、整数の画像 id が返されます。
2. その要素の set 値に [{ id, url }] を指定します。

画像を保持するには、set の際に保存済みの { id, url } をそのまま残してください。

不足している掲載画像の生成（標準レシピ）

これは、すべての掲載画像／公開画像フィールドに共通するレシピです。ビルダー、公開設定、埋め込みアプリにある すべて の App-Store 画像フィールドが対象です。

画像フィールド	設定方法	必須かどうか	寸法／制限
logo（アイコン）	app_page_builder の App Information	必須	1:1、≥ 250×250 px、JPG/JPEG/PNG
screenshots	app_page_builder の App Information	必須、3 枚以上	各 263×350 px、複数
ベネフィット画像	app_page_builder の App Features	必須、ちょうど 3 枚	benefits.image フィールドに従う（show で確認）
banner	app_publish の features セクション	任意	画像ファイル（寸法の強制要件なし）
embedded_image	app_publish の features セクション	埋め込みアプリのみ	最小 710×260 px（推奨 1420×520）、最大 512 KB

上記の寸法と枚数（ロゴは 1:1 で ≥250×250、スクリーンショットは ≥3 枚、ベネフィット画像はちょうど 3 枚）は、保存時にサーバー側で強制されます。条件を満たさない場合、action=set は error.fields を返します。これらの数値をビルダーのフロントエンドの保証とみなすのではなく、ビルダーフィールドの実際の要件は app_page_builder action=show で確認してください。

banner と embedded_image はビルダーフィールドではなく、公開設定のフィールドです。app_publish で設定してください（salla-publication-consistency）。embedded_image は Embedded App Banner で、アプリに iframe ページがある場合にのみ適用されます（2 枚目の Salla プロモーション画像も管理する salla-embedded-app）。logo はアプリ作成時にも設定されます（salla-app-builder の Step 1）。

これらの画像が不足している場合、または 初回の公開を準備している場合は、画像生成ツールを利用できるなら、アプリの目的とブランドに合った画像を生成してアップロードし、設定します。

1. まず、そのフィールドに必要な寸法とアスペクト比を確認します。上の表、およびビルダーフィールドについては action=catalog／action=show／blocks-and-fields.md を参照してください。アップロードが拒否されるのを防ぐためです。
2. アプリに合う画像を、そのサイズで生成します。
3. salla_upload でアップロードします。画像の id が返されます。
4. フィールドのツールを使って設定します。ビルダーフィールド（logo、screenshots、ベネフィット画像）は app_page_builder で、banner／embedded_image は app_publish の features セクションで設定します。

掲載画像は実物を使う — まず確認し、プレースホルダーは事前に伝えた場合のみ使用

掲載情報を完成させるには、実物の画像が必要です。logo と 3 枚以上のスクリーンショット（App Information）、banner と embedded_image（App Features。上の表を参照）です。画像が不足している場合は、次の手順に従います。

1. 必要な画像をすべてユーザーに提供してもらいます。 実物のように見える画像を勝手に作成せず、フィールドを黙って省略しないでください。これは、作り話をせず確認する方針です。（画像生成ツールが利用でき、ユーザーが生成画像を希望する場合は、上記の生成・アップロード手順を使用してください。）
2. ユーザーが提供しない、または辞退した場合は、明確にプレースホルダーと表示したデフォルト画像を使って処理を進めます。これにより、下書きの検証を通過させます。そのうえで、ワンクリック送信の前に、Portal でプレースホルダーを差し替えるようパートナーに明確に伝えてください（送信手順 → salla-publication-consistency）。プレースホルダー画像を完成版として提示しないでください。

確認事項：「すべての掲載画像はパートナーが提供した実物のアセットか、送信前に差し替えるようパートナーにはっきり伝えたプレースホルダーですか？」

自動入力：デフォルトテンプレート

公開済みのアプリには掲載ページがすでにあります。デフォルトテンプレートは公開データからレンダリングされます。app_page_builder は同じ下書きに書き込むため、一部だけをカスタマイズすると、デフォルトテンプレートと混在します。

モデル

• アプリのリスティングとは、action=list で返されるブロックの順序付き配列です。
• カタログ（action=catalog）とは、add できるブロックタイプの全セットです。
• ブロックには id、slug、order と、is_required、editable、is_visible の各フラグがあります。編集可能な入力項目は要素（キー → 値）で、action=show から確認できます。
• app-information は唯一の固定ブロックです。init でシードされ、remove では削除が拒否されます。残りの必須／任意ブロックは init／catalog で動的に明らかになります。呼び出し時に最新のセットを確認してください。

ブロック／要素のモデルと、タイプおよび要素キーの確認方法についてはブロックとフィールドを、アクションの仕様についてはAPI 仕様を、set の値の形式についてはペイロードを参照してください。ブロック ID と要素キーの例はあくまで参考例です。action=catalog／action=show で確認してください。

留意点

• 新しい下書きでは、まず init を実行してください。必須ブロックがシードされ、現在のページが返されます。
• 呼び出し時に action=catalog（ブロックタイプ）と action=show（要素キー）で ID とキーを確認してください。このスキルに記載された ID／キーの例はあくまで参考例です。
• App Information は唯一の固定ブロックです。常に存在し、先頭に配置され、削除できません。残りの必須／任意ブロックは init／catalog で明らかになります（スラッグはあくまで参考例です。呼び出し時に確認してください）。App Plans は、アプリにプランがない場合でも、リスティング上では常にプレースホルダーとして表示されます。ただし、編集可能なビルダーブロックではありません。公開フローの料金設定ステップ → salla-publication-consistency／salla-app-billing から入力してください。
• 連絡先情報は、公開情報の contact_information セクションにあります → salla-publication-consistency。一部のサポート／連絡手段は、App Information 上にフラットな support_* 要素として表示される場合もあります。action=show で確認してください。
• 言語要素には、アラビア語と英語の両方が含まれます（{ "ar": "…", "en": "…" }）。
• コレクション要素の子要素は、コレクション ID をプレフィックスとして付けたキーで指定します（features.title）。payloads.mdを参照してください。
• image と richtext の値は、公開される App Store のコンテンツとして表示されます。信頼できる、サニタイズ済みのアセット／HTML のみを使用してください。

注意すべき誤り

誘惑されやすい考え方	なぜ間違っているのか
「ロゴ／スクリーンショットが提供されていない。実物らしい画像を作って提出しよう。」	パートナーが承認していないアセットを勝手に作ることになります。まず実際の画像をユーザーに依頼してください（verify-don't-invent）。
「ユーザーが画像を提供していないので、プレースホルダーを入れて先に進もう。」	プレースホルダーを使ってよいのは、それと明示し、提出前に Portal で差し替えるようパートナーに伝える場合のみです。
「準備状況のチェックを通すため、不足している画像は黙って省略しよう。」	プレースホルダーを最終版として黙って提出することが問題です。ワンクリックで提出する前に、どの画像が仮のものかをパートナーに知らせる必要があります。

関連リンク

• salla-publication-consistency — 下書き／公開のライフサイクル（app_publish action=open、公開情報の各セクション、short_description、contact_information）。
• salla-app-builder — アプリの作成、設定、公開を最初から最後まで行います。
• salla-app-settings — マーチャントの設定。
• salla-docs — スキーマとドキュメントの検索。

Resources

Topic	Link
Partners Portal	https://portal.salla.partners
Developer blog	https://salla.dev/blog/
Developer community (Telegram)	https://t.me/salladev