salla-app-builder

Salla App Builder — アプリをゼロから作成する

説明するだけではなく、実際に操作して Salla アプリを完成させます。 各ステップでは、Salla Partners MCP ツールを呼び出して作業を行います。ステップの順番に従い、 次に進む前に各ゲートを完了してください。

根拠を確認するルール — 実際の値を読み取り、実際の結果を確認してください。

1. Salla に URL を書き込む前に、デプロイ済みドメインを必ず確認してください。 ライブの Vercel プロジェクトドメインを、vercel project ls、Vercel MCP、または .vercel/project.json で読み取ってから、 app_url、埋め込み用の iframe_url、またはスニペットの BASE を設定してください。解決できない *.vercel.app ドメインを推測すると、インストール、Webhook、iframe が気付かれないまま壊れます （書き込み時にエラーは発生しません）。
2. 変更を加えるたびに、読み戻して確認してください。 connect／update／subscribe は、最小限の内容や 空の本文を返すことがあります。フィールドのないレスポンスは、何も行われずに失敗した場合と区別できません。 変更を完了とみなす前に get／list で確認し、書き込みレスポンスだけを信用しないでください。
3. ドメインを変更する場合は、ドメインを使用しているすべての場所をまとめて更新してください — ポータルの app_url、 埋め込み用の iframe_url、スニペットの BASE、すべての環境変数。チェックリスト： references/domain-consistency.md。

手順の流れ： 作成 → 設定 → 公開。 アプリの作成は最初のゲートにすぎません — 作成したアプリは公開済みではありません。スコープ、Webhook／イベント、UI（必要な場合）を設定し、 審査を受けてから、加盟店が利用できるようになります （docs.salla.dev/421410m0.md）。 これらすべての起点はSalla Partners アカウント（認証済み）です → portal.salla.partners → マイアプリ （docs.salla.dev/421412m0.md）。以下の MCP ツールは 同じポータルを操作するため、接続されている場合はこれらを優先してください。

ツール

以下の手順では、Salla Partners MCP のツールを使用します。それぞれが action を持つ1つのツールです。

ツール	機能
salla_reference	categories、countries、cities を検索します
salla_upload	ロゴ／ファイルをアップロードし、ファイルの id を返します
salla_apps	create ／ update ／ get ／ list ／ connect（OAuth＋webhooks）／ set_status ／ demo_stores（テスト）。公開アプリの公開には別の app_publish ツールを使用します。プライベートアプリには salla_private_apps を使用します。
salla_private_apps	プライベートアプリ：status（app_id なし＝アカウント種別）／ publish（確認必須）／ withdraw ／ ストアリクエスト（list_requests get_request create_request update_request delete_request）→ references/private-apps.md
salla_scopes	有効なスコープのスラッグ（disabled ／ selected を含む）を get し、選択したスコープを設定します（フラットな slug → read | read_write | ""）
salla_events	購読可能なイベントを list し、アプリをスラッグに subscribe します

前提条件： Salla Partners MCP サーバーに接続されている必要があります（上記のツールがツール一覧に表示されます）。接続されていない場合は、ポータル（https://portal.salla.partners）とインラインの手動メモを使用してください。ツールから「Salla session expired — reconnect」が返された場合は、OAuth／ログインフローを実行してください。

ステップ 0 — アプリの要件を確認する

開始前に、次の点を確認してください。

1. アプリの機能は何ですか？（簡単な説明）
2. アプリの種類： General ／ Communication ／ Shipping
3. 公開範囲： Public（App Store）または Private（招待制）

これらは互いに独立した2つの選択肢です（docs.salla.dev/421410m0.md）。Public アプリは、あらゆるマーチャントが閲覧、ダウンロード、購入できる Salla App Store に表示されます。Private アプリは特定のマーチャント向けに作られ、ストアの一覧や検索結果には表示されません。Category（General または Shipping）は別の軸です。アプリの type は単一の値（app ／ private ／ shipping ／ communication）であるため、Shipping アプリは常に Public であり、Communication アプリも通常は Public です。公開範囲はタイプごとにポータル側で適用されるため、組み合わせを決めつけず、create／公開時の検証に任せてください。

回答に基づいて、ステップ 1、4～7 を調整してください。

---

ステップ 1 — アプリを作成する

1. カテゴリーを解決します。 action: "categories" と type（"app" または "shipping"）を指定して salla_reference を呼び出し、sub_categories を取得します。そこから create の sub_category_id を選択します（一致しないサブカテゴリーは拒否されます）。プライベートアプリもここでは type: "app" を使用します。"private" は有効な salla_reference のカテゴリータイプではありません。app／shipping の場合、create では sub_category_id が必須です（app の選択肢は POS、OMS、Subscription、Cross-sell/Upsell、Manage Store、AI、Others です）。同じ呼び出しで main_categories／categories も返されますが、まだ使用しないでください。これは、この手順ではなく、publish の main_category_id／categories 用の、タイプに依存しない「App Theme」／「App Impact」リストです → salla-publication-consistency。
2. ロゴをアップロードします。 公開画像の source_url を指定して salla_upload を呼び出します。ロゴは 正方形（1:1）の画像で、250×250 px 以上である必要があります。アップロードする前に、元画像がこの条件を満たしていることを確認してください。結果として返されるのは {id, url} のみ（寸法は返されません）なので、返された id を使用します。作成時にロゴがなく、画像生成ツールが利用できる場合は、画像を生成（1:1、250×250 以上）してアップロードします。完全な標準手順（およびその他すべての掲載／公開画像フィールドとその寸法） → salla-app-ui-builder。
3. アプリを作成します。 Salla が作成時に必要とする基本情報は アイコン、名前、カテゴリー、説明、アプリのウェブサイト、サポート用メールアドレスです (docs.salla.dev/421410m0.md)。MCP では、これらは以下のフィールドに対応します。action: "create" を指定して salla_apps を呼び出し、次を渡します。 | フィールド | 要件 | | ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | name + name_ar | Salla はアプリ名を、発音記号やタシュキールを使わないアラビア語の文字で指定することを求めています（例：هرّفاي ではなく هريفاي）。また、Salla アプリ間で一意である必要があります。これらの要件は Portal 側で検証されるものとして扱ってください。事前にクライアント側で確認するのではなく、create で検証し、送信後にエラーに対応します（名前が使用済みまたは無効な場合は、名前を変更して再送信します）。判断に迷う場合は、create のレスポンスで正確な制約を確認してください。 | | type | 手順 1 の値（private または公開カテゴリ） | | short_description (+_ar) | それぞれ 50～200 文字です。name と同様に二言語で指定します。 | | app_url | アプリの公開 URL です。推測した *.vercel.app ではなく、デプロイ済みの Vercel プロジェクトから読み取ってください（グラウンディングルール 1）。これはソースドメインです。後で変更した場合は、ここも更新してください（手順 1 のゲート／ドメイン整合性チェックリスト）。 | | email | サポート用メールアドレス | | logo | salla_upload から取得したファイルの id | | sub_category_id | type が app または shipping の場合に必須です。 | | is_paid | プライベートアプリで必須です。手順 3a の private_app_is_paid を渡してください。 | 3a. プライベートアプリのみ： create の前に、app_id を指定せずに salla_private_apps action=status を呼び出し、その private_app_is_paid を is_paid として渡します（マーチャントパートナーは "0"、Salla が無料のプライベートアプリを許可していない限り、通常のパートナーは "1" です）。ルール → references/private-apps.md。

結果には新しい app_id が返されます。以降のすべての手順でこの値を引き継いでください。アプリを Partners Portal で開き、表示、設定、テストしてください： https://portal.salla.partners/apps/{app_id}（返された ID に置き換えてください）。作成後は毎回、このリンクをユーザーに提示してください。この App Details ページが、次の手順で設定するすべての項目（App Keys（Client ID/Secret、OAuth モード）、Scope、Webhooks、Trusted IPs、App Functions、Settings、Onboarding、Embedded Pages、Snippets、Custom Plans、Testing、Publishing）のハブになります（docs.salla.dev/421410m0.md）。

salla_apps action=update に関する注意： Portal はレスポンス本文を返さないため、ツールは変更したフィールド（{ app: { id, …changed, updated: true } }）を確認としてそのまま返します。これは入力内容を反映したものであり、サーバーに保存された状態ではありません。重大な変更の場合は、salla_apps action=get で読み戻し、値が実際に保存されたことを確認してください。

手動での代替方法： Portal → My Apps → Create App。

確認事項：「アプリが作成されました。返された app_id（salla_apps action=get）を確認し、type: private の場合は is_paid が salla_private_apps action=status から取得された値であることを確認してください。」アプリは作成されただけではまだ公開されていません（docs.salla.dev/421410m0.md）。設定から公開まで続けてください。

作成時の注意点

つい考えてしまうこと	それが誤りである理由
「create が拒否された — 『N 個を超えるプライベートアプリは作成できません』と表示された。機能が無効になっているに違いない。」	アカウントに残っている無料のプライベートアプリがありません（通常のパートナーにはデフォルトで無料枠がありません）。salla_apps action=create で is_paid: "1" を設定し、有料アプリとして作成してください。

ステップ 2 — OAuth、スコープ、Webhook 接続

Easy Mode をデフォルトにしてください。 Easy Mode（app.store.authorize webhook 経由のトークン取得、コールバックなし）は、すべてのアプリに推奨されるデフォルトです。具体的な技術上の理由で動作しない場合を除き、これを使用してください。Custom Mode（OAuth /callback コード交換）は、開発中のローカル開発／Postman 用です。実際に正当なユースケースがないまま Custom Mode で公開アプリをリリースすると、審査で却下される可能性があります。各モードの仕組み → salla-app-auth。

OAuth と webhook は、salla_apps action=connect の 1 回の呼び出しで設定します。まず、アプリで有効なスコープのスラッグと現在の選択内容を確認します。

1. action: "get" と app_id を指定して salla_scopes を呼び出し、有効なスコープのスラッグ、現在の選択内容、アプリごとの disabled フラグを確認します。（スコープカタログを参照するエンドポイントはありません。salla_scopes はアプリからスコープを読み取ります。）最小権限： アプリに必要な最小限のスラッグだけをリクエストし、アプリが実際に書き込みを行う場合を除き、read_write より read を優先してください。過剰なスコープは審査の遅延や却下につながるおそれがあります。disabled オプションは保存されないため、get で取得したフラグに従ってください。マーチャントパートナーのプライベートアプリでは、shippings、settlements、subscriptions、customer_wallets は非表示です（許可リストによる例外はありません）。一般のパートナーのプライベートアプリでは、Salla がアプリを許可リストに登録しない限り、shippings は無効です。制限されたスコープは保存されず、salla_scopes action=set の結果で dropped の下に表示されます → references/private-apps.md。

2. action: "connect"、app_id と、必要に応じて以下の項目を指定して salla_apps を呼び出します。

   • scopes — slug → "read" | "read_write" のマップ（例： {"orders": "read", "products": "read"}）。ここにはリソースのマップのみを渡してください。offline_access は OAuth 認可 URL に含めるものであり、scopes のマップには含めません。 （salla_scopes action=set を単独で呼び出して、選択内容を変更することもできます。）
   • redirect_urls — OAuth リダイレクト URL。HTTPS のみです。許可リストは厳格にし、実際に使用するコールバックだけを登録してください。
   • webhook_url — webhook の受信先（HTTPS のみ。以下の署名／トークン方式で受信リクエストを認証する必要があります）
   • webhook_security_strategy — "signature"（推奨）または "token"
   • trusted_ips、webhook_headers

   一部の処理が失敗した場合は _partial の下に返されます。失敗した項目のみを再適用してください。

connect は webhook 署名シークレットを新規発行またはローテーションしません。Partner Portal（https://portal.salla.partners/apps/{app_id}）で新規発行またはローテーションしてください。そこでローテーションすると、古い値は無効になります。salla_apps action=get の webhook_secret フィールドで現在のシークレットを読み取り、シークレットマネージャーに保存してください（ソースコード／リポジトリには絶対に保存しないでください）。この値は、すべての webhook で HMAC-SHA256 署名を検証するために使用します。デプロイの直前に最新の値を読み取り、セッションをまたいで持ち越した値は絶対に再利用しないでください。署名検証と冪等性 → salla-webhooks スキル。トークンの取り扱い（Easy Mode と Custom Mode、保存、更新） → salla-app-auth スキル。（ここではルーティングのみを行い、再実装しないでください。）

ゲート：「スコープ、リダイレクト、webhook が適用され（_partial なし）、読み戻し（salla_scopes action=get／salla_apps action=get）で、スコープ、リダイレクト、webhook URL が実際に反映されたことを確認できましたか（Grounding rule 2）。webhook URL は稼働中のデプロイドメイン（Grounding rule 1）を指し、200 を返し、シークレットは保存されていますか？」

---

ステップ 3 — ストアイベントのサブスクリプション

1. salla_events を action: "list" および app_id とともに呼び出し、アプリがサブスクライブできる有効なイベントスラッグを取得します （スラッグは検証されるため、必ず最初に呼び出してください）。
2. 「アプリが反応するドメインはどれですか？」と尋ねます。必要なイベントのみサブスクライブするには、 salla_events を action: "subscribe"、app_id、および events: [...slugs] とともに呼び出します。

フック可能なルール — まず App Functions を確認してください。 ストアイベント （注文／商品／カート／顧客など）の Webhook をサブスクライブする前に、App Function のトリガーカタログ （salla-app-functions）を確認し、App Function を優先してください。Salla 内で実行され、context.settings を読み取り、 独自のトークン／更新処理や署名検証なしで Salla API を呼び出します。トリガーがないライフサイクル／認証イベント （app.store.authorize（Easy-Mode トークンを配信）、インストール／アンインストール、トライアル／サブスクリプション）には、 Webhook のみを使用してください。適切な使い分けは、ライフサイクル／認証 → Webhook · ストアの自動化 → App Function · ストアフロント UI → スニペット · マーチャント設定 → 埋め込みダッシュボードです。

ドメイン別の一般的なスラッグ：

ドメイン	主なイベント
ライフサイクル（常時）	app.store.authorize、app.installed、app.uninstalled、app.updated、app.subscription.started
注文	order.created、order.updated、order.status.updated
商品	product.created、product.updated、product.deleted
顧客	customer.created、customer.updated
配送	shipment.created、shipment.cancelled、shipment.updated（非同期 Webhook） — shipment.creating／shipment.cancelling は同期 App Function です（salla-shipping-app を参照）

イベントが配信される前に、webhook_url を設定しておく必要があります（ステップ 2）。不明なスラッグは、有効なスラッグの一覧とともに 拒否されます。一覧から選択してください（salla_events action=list が正しい情報源です）。

確認: 「サブスクライブできました。デモストアからイベントを 1 つ発生させ、Webhook が受信することを確認してください。」

---

ステップ 4 — ストアフロントのスニペット

「アプリでマーチャントのストアフロントに HTML／JS を挿入する必要はありますか？」と尋ねます。

• はい → salla-snippets スキルに従います（salla_snippets を使用して スニペットを作成します）。
• いいえ → ステップ 5 に進みます。

---

ステップ 5 — 埋め込みアプリページ

「アプリで Salla のマーチャントダッシュボード内にカスタム UI が必要ですか？」と尋ねます。

• はい → salla-embedded-app スキルに従います（salla_embedded_pages を使用して iframe ページを登録し、SDK の設定、認証、テーマの同期も行います）。
• いいえ → ステップ 5a に進みます。

---

ステップ 5a — インストール後のオンボーディング手順（任意）

「アプリのインストール直後に、マーチャントにガイド付きセットアップ手順を表示する必要がありますか？」 オンボーディングフローは任意で、設定する場合は各マーチャントの初回インストール時に一度だけ実行されます。よくある用途として、アプリの有効化前に認証情報（メールアドレスとパスワードなど）を収集する、ストアのプロフィール情報を取得する、後から変更できない設定を構成するといったものがあります。

• はい → 各ステップは順番に作成する必須の2つの要素で構成されます。まずステップ（フォーム。fields は空ではないこと）、次に App Function ハンドラーです。salla_onboarding_steps action=create でステップを作成します（icon、title、slug はすべて必須です。title は単一言語のプレーンな文字列で、{ar,en} ではありません。ステップに url はありません。fields は必須で、パブリックアプリ設定と同じスキーマです。sort と required は任意です）。ステップの表示順を変更するには action=sort、管理には action=list／delete を使います。続いて、action=list でステップの存在を確認してから（トリガーは保存済みステップから解決されるため、先にハンドラーを保存すると「Unknown trigger」が返されます）、salla_functions action=save でハンドラーを追加します（トリガー app.onboarding.step.creating.{slug}、コンテキスト Onboarding）。マーチャントの入力は context.payload.data.fields として渡されるため、検証やカスタムロジックの実行に利用できます。Resp.success() を返すと続行し、Resp.error().setFields(...) を返すと処理を停止してフィードバックを表示します。ハンドラーは再入可能である必要があります。有効化前にマーチャントが編集して再保存できるため、送信のたびに実行されます。各実行で upsert と再検証を行ってください。認証情報はプロバイダー側で検証し、暗号化またはハッシュ化した状態でのみ保存してください。ツールの全パラメーター、厳守事項、update の再検証ルール、ハンドラー、完了ペイロードの形式については、references/onboarding-steps.md を読み込んでください。
• いいえ → ステップ 6 に進みます。

---

ステップ 6 — App Functions

「Salla のイベントをトリガーとするサーバーレスハンドラーが必要ですか？」

• はい → App Function のソース、コンテキストの形式、Resp API、タイムアウトについては、salla-app-functions スキルに従ってください。App Functions はストアイベントの自動化（対応するトリガーがある場合）を処理します。ライフサイクル／認証イベントはウェブフックを使います（ステップ 3。salla-app-lifecycle／salla-app-auth が担当）。

salla_functions action=save（app_id、trigger、content、name）で関数を保存します。これは upsert（作成または更新）です。 保存した関数は、アプリのデモストアではすぐに有効になります。実際のストアで有効になるのはアプリの公開後です（ステップ 8）。salla_functions action=get で読み取り、action=delete で削除します。（salla_functions はオペレーター限定です。MCP デプロイ環境で App Builder サービスが有効でない場合は、そのことを明示するエラーが返されます。）詳細 → salla-app-functions。

確認事項：「関数を保存し、デモストアで動作することを確認しましたか？」（本番環境への公開は後の専用の公開ステップで行います。ここでは行いません。）

---

ステップ 7 — アプリの種類に応じた設定

ステップ 0 で選択したアプリの種類に応じて分岐します。

General App

マーチャントごとの設定（API キー、トグル、URL）が必要ですか？ → salla-app-settings スキルに従ってください（salla_settings action=define_form を使います）。

Communication App

マーチャントに代わってメッセージ（WhatsApp、SMS、メール）を送信します。

• type にコミュニケーションのカテゴリーを指定して作成します。コミュニケーションアプリでは sub_category_id は指定しません。
• 公開の必須条件： 公開前に salla_settings action=set_features でサポートする機能（sms_local、sms_international、email_all、whatsapp）を宣言する必要があります。宣言せずに送信すると 403 が返されます。
• 全体のフロー（チャネル、ペイロード、配信状況）については、salla-communication-app スキルを参照してください。

配送アプリ

配送業者またはフルフィルメントプロバイダーと連携します。

• 通常は Public です。Private を対象とする場合は、許可されていると想定せず、create／公開時の検証に任せてください。
• salla-shipping-app スキルに従ってください（ゾーン／設定には salla_shipping、ライフサイクル全体には salla_apps を使用します）。

---

ステップ 8 — テスト、ドラフトの検証、パートナーへの引き継ぎ

Public アプリと Private アプリ — 公開方法の違い

公開前にアプリの種類に応じた手順を決めてください。両者のフローは共通ではありません。

• type が private の場合（ストアリクエストを通じて特定の加盟店のみがインストール）→ salla_private_apps：status → publish（confirm: true、パートナーが確認した後に限ります。加盟店パートナーのアプリは通常すぐに公開されます）→ ストアごとに create_request。オンボーディング、公開リスト掲載、準備状況セクションはありません。以下の app_publish フローはすべてスキップしてください。全手順 → references/private-apps.md。
• それ以外（公開アプリ — App Store に掲載され、すべての加盟店が検索／インストール可能） → 以下のサブステップ 1〜4 にある、手順に沿った app_publish オンボーディング：open → セクションごとにガイドに従って set → app_publish action=validate（検証してドラフトを保存）→ パートナーに Portal でワンクリック送信するよう案内します。カテゴリ、価格、スクリーンショット、メリット、連絡先など、公開リストの情報一式が必要です。手順 → salla-publication-consistency に従ってください。

判定ゲート：「type は private ですか？ → salla_private_apps action=status app_id → パートナーが明示的に確認 → confirm: true を指定して publish → 公開が approved になったら（通常のパートナーのアプリは、まず Salla の審査に進みます）、ストアごとに create_request（references/private-apps.md）。そこで停止します。app_publish もオンボーディングもありません。それ以外の場合は、以下の公開アプリ用 app_publish フローに進んでください。」

1. デモストアでテストします。 salla_apps action=demo_stores、app_id で会社のデモストアを一覧表示します。各ストアでは次の情報が返されます。

   • connected — true の場合、そのストアにはアプリがすでにインストールされています。
   • install_url — ブラウザーで開くと、そのストアにアプリをインストールできます。
   • dashboard_url — ストアの管理画面に自動ログインします（埋め込みダッシュボードを開く、設定を変更するなど）。
   • url — ストアフロントのプレビューです（商品ページのスニペット／緊急性を示す表示を確認できます）。

   ストアを選び、install_url を開いてインストールした後、dashboard_url を開いて管理し、サブスクライブした各イベントを発生させてエンドツーエンドの動作を確認します。これらのリンクをユーザーに提示してください。Portal でアプリ自体を開くこともできます。 https://portal.salla.partners/apps/{app_id}

2. 準備ができたら、アプリを公開状態にします。salla_apps action=set_status、status: "live"。

3. 検証してドラフトを保存します。 エージェントがターミナルから実行する公開アクションは送信ではなく検証です。各セクションを検証し、ドラフトを保存して、そこで終了します。ガイド付きの手順を使用してください。

   • 推奨 — ガイド付きの段階的な app_publish： open → （<section>を設定 → readiness）* → validate。openは下書きを作成し（リスティングページ用の app_page_builderも利用可能になります）、次に5つのセクション（basic_information、 features、pricing、contact_information、service_trial）それぞれについて setを呼び出し、readinessを再確認して、返されたmissingリストをもとにセクションを 1つずつ修正し、すべてのセクションがcompleteと表示されるまで続けます。その後、 app_publish action=validateを実行して下書きを検証し、保存します。初回公開は ガイド付きのオンボーディングであり、むやみに入力するものではありません：各セクションには パートナーのビジネス上の判断（リスティングのコピー、カテゴリ、価格、連絡先）が含まれるため、 セクションごとにパートナーに確認し、Sallaに即した選択肢を提案して、その回答に基づいて入力して ください。内容を勝手に作り出してはいけません。セクションのフィールド、ガイド付き オンボーディングのルール、リスティング画像のルール、Portalへの引き継ぎについては → salla-publication-consistency（具体的な 手順ではこれに従ってください）。 同じサーバー側のゲート（app_publish action=validate）が実行され、準備ができていない場合は、 未完了のセクションとともに422を返します。リスティングのコンテンツ （名前／説明／ロゴ／スクリーンショット／メリット）はapp_page_builder → salla-app-ui-builderで記述します。プラン／アドオンの価格設定は → salla-app-billing。

4. パートナーが確認した後、公開リクエストを送信します。 validateで保存されるのは下書きのみです。 検証に問題がなければ、アプリの実際のIDを入れた正式な/publishリンク（プレースホルダーは 絶対に使わないでください）をパートナーに伝え、そこで下書きを確認するよう依頼します： https://portal.salla.partners/apps/{app_id}/publish （例：.../apps/1234567/publish）。Sallaの審査に進むのは、Portalでワンクリック送信するか、 パートナーから明示的な確認を受けた後にapp_publish action=send_publish_request （confirm: true）を呼び出した場合のみです。確認より前に送信してはいけません。送信され、 承認されると、https://apps.salla.sa/en で公開されます。手順 → salla-publication-consistency。

テストガイド：references/demo-store-testing.md

ゲート：「各セクションを検証して下書きとして保存し、パートナーが正式な/publishリンクを確認したうえで、 ワンクリック送信または明示的な確認があった場合にのみ公開リクエストを送信していますか？」

レッドフラグ — 公開

誘惑されがちな考え	それが間違っている理由
「これはプライベートアプリだから、公開用の app_publish オンボーディングを実行して公開しよう。」	プライベートアプリでは、段階的な掲載フローは使用しません。salla_private_apps action=publish で公開します（パートナーの確認後に confirm: true を指定します）。セクションも、オンボーディングも、掲載もありません。
「app_publish action=submit を実行して、準備状況のゲートを通じてプライベートアプリを申請しよう。」	プライベートアプリには検証対象となる公開掲載がないため、公開用の validate ゲートは適用されません。salla_private_apps を使用してから、create_request でストアに送信します。
「app_publish action=validate に合格したので、公開アプリは審査に申請された。」	validate は検証を行い、DRAFT（下書き）を保存するだけで、申請は行いません。パートナーに実際の /publish リンク（.../apps/{app_id}/publish）を案内してください。パートナーがワンクリックで申請するか、明示的な確認後に send_publish_request（confirm:true）を使用した場合にのみ、審査依頼が Salla に届きます。

---

リソース

トピック	リンク
はじめに	https://docs.salla.dev/421412m0.md
最初のアプリを作成する	https://docs.salla.dev/421410m0.md
パートナーポータル	https://portal.salla.partners/
アプリマーケットプレイス	https://apps.salla.sa/en
Webhook ガイドとイベント一覧	https://docs.salla.dev/421119m0.md
アプリイベント（ライフサイクル）	https://docs.salla.dev/421413m0.md
Salla Admin API リファレンス	https://docs.salla.dev/421117m0.md
開発者コミュニティ（Telegram）	https://t.me/salladev