# Marketplace

The marketplace is where workflows and custom connectors get shared. Publish your own workflows as templates, publish reusable connector manifests, and install community assets into your workspace.

## What gets shared (and what doesn't)

A workflow listing contains a **snapshot of the workflow graph** — nodes, edges, prompts, schemas, node configuration. A connector listing contains a **snapshot of the custom connector manifest** — connector id, action definitions, input/output schemas, docs, and default HTTP request data.

Explicitly **not** included:

- **Credentials.** API keys, OAuth tokens, stored credentials — never copied.
- **Deployment config.** API keys for publishing, webhook secrets, channel tokens (WhatsApp, Telegram, Slack) — stay private.
- **Run history, generated files, version labels.**

When someone installs your workflow listing, they get an editable draft copy of the graph. When someone installs your connector listing, they get a new custom connector in their current workspace. They have to wire their own credentials before either one runs.

If a workflow uses custom connector actions, the workflow listing keeps the connector operation ids on the nodes and includes sanitized snapshots of the source workspace's custom connector manifests. Install preview reports whether each connector is already available, will be installed, collides, or is invalid/missing.

## Portability checklist

Marketplace assets should depend on stable contracts, not on local account objects:

- Keep custom connector metadata on workflow nodes: `connectorId`, `connectorActionId`, and `connectorOperationId`.
- Keep the custom connector installed in the source workspace before publishing so the workflow snapshot can bundle its manifest.
- Publish a companion connector listing when you also want standalone discovery and reuse of that connector.
- Treat credentials, webhook secrets, workspace IDs, and provider-specific resource IDs as installer setup. Install preview marks removed credential references as required setup.
- If the target workspace already has the same connector id with a different manifest, workflow install is blocked until the connector collision is resolved.

## Publishing

From the workflow editor, publish workflows with **Marketplace** in the top bar. From Production > Connectors, publish saved custom connectors with **Publish**.

For workflow listings:

1. Click **Marketplace** in the editor's top bar.
2. Fill the form:
   - **Title** (required, ≤ 255 chars)
   - **Description** — what it does, what credentials it needs, what to watch out for. Markdown is fine.
   - **Category** — pick one (`productivity`, `sales`, `support`, `devops`, `marketing`, etc.). Used for filtering.
   - **Tags** — free-form keywords; helps search.
   - **Icon** — optional emoji or lucide icon name.
3. Hit **Publish**. The listing goes public immediately under your account.

A snapshot is taken at publish time. Later changes to your workflow do **not** update existing listings — republish (or edit the listing's description) to ship a new version.

Connector listings are versioned snapshots. Later edits to the source connector do **not** update an existing marketplace version automatically.

## Connector versions and changelogs

Connector listing metadata can be edited, but each published connector manifest version is immutable. A connector version keeps the normalized manifest, `manifest_hash`, operation ids, schemas, auth profiles, HTTP defaults, changelog, publisher, and publish date as they were at publish time.

Publish a changed manifest to create a new connector version with a new changelog. The existing installed copies keep running on the version they installed until someone chooses to upgrade.

When a connector is installed, the marketplace keeps an install record linking the listing, installed version, local connector, installed manifest hash, owner/workspace, and status. That record lets the upgrade preview compare what is installed locally against the latest marketplace version.

## Connector moderation and trust

Connector listings have a moderation status: `pending`, `approved`, `rejected`, or `suspended`.

- `pending` — submitted and waiting for review.
- `approved` — trusted for public browse and install.
- `rejected` — not accepted; the owner can correct and resubmit.
- `suspended` — previously visible or installable, now blocked by moderation.

Public browse, listing detail, install preview, install, and upgrade flows must trust only `approved` connector listings. Non-approved listings are hidden from public marketplace discovery and blocked from public installation. Listing owners can still see their own `pending`, `rejected`, and `suspended` listings to fix metadata or manifests. Admins can see every status for moderation.

Admins update connector moderation with `PATCH /api/v1/marketplace/connectors/{public_id}/moderation`. The moderation payload sets the new status and an optional reason that is returned as trust metadata, not as a secret-bearing manifest field.

## Connector risk scanner

Every connector marketplace listing exposes a `risk_summary` generated from the sanitized manifest version. The listing detail and install preview use the same endpoint data so users can inspect behavior before installing or upgrading.

The scanner summarizes:

- Moderation status and moderation reason.
- Risk level (`level`: `low`, `medium`, or `high`).
- External domains called by connector actions.
- HTTP methods used by each action.
- Required auth profiles and whether a credential will be needed after install.
- Manifest/action/schema signals such as action count, missing input schemas, placeholder hosts, non-HTTPS URLs, body-on-GET, dynamic URLs, sensitive query parameter names, and other warnings.

The trust summary completes `risk_summary` with `moderation_status`, `moderation_reason`, and `level`. It is intentionally metadata-only. It never includes credentials, OAuth tokens, API keys, secret headers, secret query/body values, publisher workspace ids, or provider resource ids. Sensitive values are redacted or replaced by setup-required markers before the summary is stored or returned.

UX value: connector cards show the high-level risk status quickly, while the detail page explains which domains, methods, auth requirements, and warnings are involved. Install decisions are therefore based on visible behavior rather than trust in the listing description alone.

## Browsing

Left sidebar → **Marketplace**, then choose **Workflows** or **Connectors**.

- Full-text search across title and description.
- Filter by **category**.
- Newest listings appear first.
- Workflow cards show title, description, owner email, install count, node count, tags, and compatibility status.
- Connector cards show title, description, owner email, install count, action count, connector id, tags, moderation status, risk level, and install compatibility.

Public connector browsing shows only approved listings. Use **My listings** to inspect your own pending, rejected, or suspended connector listings; admins can use moderation views to inspect all statuses.

Click any card to see the full description and a preview. Workflow previews show the graph. Connector previews show actions, methods, URLs, diagnostics, and collision blockers.

## Installing

From a listing detail page → **Install**.

For workflow listings the system:

1. Creates a new workflow in your account named `<original title> (from marketplace)`.
2. Copies the nodes and edges as-is.
3. Marks the new workflow as a draft: `is_active = false`.
4. Installs bundled custom connectors that are missing from the target workspace.
5. Increments the listing's `install_count`.

If a bundled connector collides with an existing connector that has a different manifest, install is blocked until the conflict is resolved.

You land in the editor. From here:

- **Wire credentials** — every Agent, MCP, HTTP, or OAuth-backed node will show a "credential not set" warning. Click each, pick a credential from your credential store (or create one).
- **Re-check triggers** — webhook paths, schedule cron expressions, Gmail/Notion poll configs are copied but not activated. Visit each trigger node, set what it should watch, save.
- **Test in the chat preview** before publishing.

For connector listings the system:

1. Requires an `approved` marketplace connector listing for public install.
2. Validates the manifest against the current workspace.
3. Blocks install if the connector/action ids collide with a built-in or custom connector already installed.
4. Creates a new enabled custom connector in the current workspace from the selected immutable version.
5. Records the install with the listing, version, local connector, and manifest hash.
6. Increments the listing's `install_count`.

You stay on the marketplace page. Open Production > Connectors to inspect or edit the installed connector.

## Connector upgrades

Before replacing an installed connector manifest, use the diff/upgrade preview. The preview is read-only and reports:

- Added, removed, and changed actions.
- Input/output schema changes.
- Auth profile changes.
- HTTP method, URL, header, body, and docs changes.
- Workflows and nodes in your workspace that use affected operation ids.
- Breaking changes, warnings, registry collisions, and whether confirmation is required.

The preview never includes credentials, secrets, or source-workspace resource ids. Applying an upgrade updates the local connector manifest and install record to the target version; workflows keep their operation ids, but breaking schema or removed-action changes may require editing affected nodes.

Workflow listings can bundle custom connector manifests. If the target workspace already has the connector installed from an older marketplace version, install preview should show the connector diff/upgrade preview instead of silently replacing the local manifest.

## Managing your listings

From the marketplace page → tab **My listings** (or pass `?owner=me`).

You see every listing you own — public or unlisted. For each row:

- **Edit** — change title, description, category, tags, icon. Edits are instant.
- **Toggle visibility** — `is_public: false` hides it from search but keeps the install link working for anyone who already has it.
- **Unpublish (delete)** — removes the listing entirely. Already-installed copies in other accounts are not affected (they're independent workflows).

## Good listings vs. bad listings

Things that make a listing useful:

- A description that says **what credentials are required** ("needs a Gmail OAuth credential and a Notion integration token").
- A description that says **what the workflow does** in one sentence, then bullets the steps.
- Tags that match how people search (`crm`, `hubspot`, `daily-digest`).
- A small graph — 3-7 nodes is the sweet spot. 30-node monstrosities are hard for others to adapt.

Things to avoid:

- Hard-coded user-specific values in prompts (your email, your company name).
- Vendor-locked node configs that won't work without a specific credential ID — referencing by name is fine, by raw ID is not.
- Test workflows. Mark them unlisted or don't publish.

---

*Source: https://agentbuilder.systalink.sn/docs/marketplace — human documentation.*
*Other language: [/docs-md/fr/marketplace.md](/docs-md/fr/marketplace.md).*
*Machine-readable index: [/llms.txt](/llms.txt).*