Publishing to the marketplace

Publishing turns a working connector or operator pack into a listing other tenants can install. The mechanics are one command; the substance is the listing metadata, which the marketplace renders directly and the Fibric team reviews before anything goes live. During early access, review is a conversation with the team, proposals are considered individually, and the bar is the same one the five live listings cleared.

#Listing metadata requirements

A listing has two layers: the card shown in the marketplace grid, and the detail page behind it. Every field below is real; these are the fields the live catalog is built from, and review checks each one.

#Card fields

#Detail page fields

#A complete listing.json

The listing travels with the project as listing.json. This example is complete: every required card and detail field, in the register the marketplace expects.

{
  "id": "cn-brightdesk",
  "name": "Brightdesk",
  "category": "comms",
  "type": "connector",
  "caps": "reads conversations and SLA state · writes notes back idempotently",
  "blurb": "Reads Brightdesk conversations as governed events and writes notes back under idempotency, so a retried write is a safe no-op.",
  "tags": ["support", "cx", "conversations", "helpdesk"],

  "tagline": "Brightdesk conversations in, notes back — idempotently.",
  "about": [
    "The Brightdesk connector reads conversations, messages, and SLA state as governed events: every thread stamped with its tenant, its source, and the moment it changed, so an operator sees the conversation the way an agent would.",
    "Writes go the other way under the same discipline: notes are idempotent, so a retried write collapses into the original rather than duplicating. Side effects run only through the deterministic executor, behind the tenant's trust policy."
  ],
  "senses": [
    "Conversations and messages as they arrive and change",
    "SLA state and breach events per conversation",
    "Customer records with contact history"
  ],
  "acts": [
    "Writes notes to a conversation, idempotently",
    "Updates conversation status and assignment"
  ],
  "auth": "A Brightdesk API key with the scopes you grant, stored in your tenant's secret store.",
  "requires": [
    "A Brightdesk instance and an API key with conversation read and note write scopes"
  ],
  "worksWith": ["op-order-sentinel", "op-radar-analyst"]
}

#Submitting

fibric publish validates the def and the listing together, then submits the proposal for review. Nothing becomes visible to other tenants at this point.

$ fibric publish ./connectors/brightdesk
  validating def          cn-brightdesk@1.0.0  ok
  validating listing      listing.json          ok
    card: id, name, category, type, caps, blurb, tags        ok
    detail: tagline, about[2], senses[3], acts, auth,
            requires, worksWith                              ok
    worksWith references resolve: op-order-sentinel, cn-magento  ok
  running contract tests  4 tools, 3 events     ok

  submitted proposal pub_01j9x2 for review.
  status: proposed. the Fibric team will follow up on this proposal;
  track it with: fibric publish --status pub_01j9x2

#The review process

Fibric is in early access, and review reflects that honestly: proposals are reviewed by the Fibric team, individually, with a person on the other end. There is no automated approval path yet. Review covers four things, in order:

1. Contract. The def satisfies the SDK contract: every tool validates its input, every side-effecting tool is flagged sideEffecting, the declared auth kind matches how the connector actually authenticates, and the probe answers.
2. Secrets. No credential material in code, config, or logs, per the secret handling rules. This is the most common reason a proposal goes back.
3. Listing accuracy. Every claim in about, senses, and acts is checked against the tool and event surface. Production-use claims require a running deployment the team can verify.
4. Behavior. The team runs your fixture corpus through the harness and exercises the tools against a sandbox connection you provide. For operator packs, the prompt contract and guardrail defaults get a dedicated read.

Expect dialogue rather than a verdict. The five live listings each went through at least one revision cycle, and turnaround during early access is days, not weeks.

#Pricing your listing

Pricing is part of the proposal and shows on the detail page. The platform's standing terms frame what you choose:

Choose free unless the connector carries ongoing cost or genuine depth; a premium price on a thin wrapper will not survive review. Pricing changes after launch apply to new installs only; existing installs keep the terms they installed under until they upgrade a major version.

On paid listings you keep 97% of gross transaction value; Fibric retains a 3% listing fee (2% on private offers over $1M/year, 1.5% over $5M/year). Checkout runs on Stripe; payouts arrive monthly through Stripe Connect. Free listings pay no fee. Register as a publisher at fibric.io/sell/register.

#Status lifecycle

Every listing moves through three states, and only review moves it forward:

Status attaches to the listing, versions attach to the artifact. A new version of a live listing does not reset its status, but a major version with new required capabilities gets a fresh behavioral review before it is offered to installers. Deprecation is explicit and never deletes: a deprecated version stays installable-in-place forever, because someone's production depends on it.

#Updating a live listing

Publishing a new version of an existing listing is the same command against the same id with a bumped version. What review looks at depends on what changed:

• Listing-only changes (a sharper tagline, an added worksWith reference) are reviewed for accuracy only and typically turn around fastest.
• Patch and minor artifact versions get a contract re-check and a fixture replay. The listing keeps its status.
• Major versions, anything that adds a required capability, changes the auth kind, or (for packs) alters guardrail defaults, get a fresh behavioral review before the version is offered to installers.

Existing installs are never force-upgraded. A tenant running cn-brightdesk@1.0.0 keeps running it after 1.1.0 ships; the upgrade is their decision, made against the diff the marketplace shows them.

#Keep going

• Testing connectors: the fixture corpus and CI gates review expects you to arrive with.
• defineConnector(): the def the listing must accurately describe.
• Operator packs: the extra review surface packs carry, prompt contract and guardrails.
• CLI reference: fibric publish flags and output in full.