Skip to main content
Amends 0218 (decision 5: the marketplace model is decided here) and 0308 (rule 21: third-party publishers are in scope, behind review), each by a Note.

​
Context

0218 decision 5 left the marketplace model to Figentra OS. 0308 rule 21 put third-party publishers out of scope. Nothing said how one provider that plays several parts (Slack is a chat channel, an app surface and a workflow trigger) is described once, or which providers a tenant sees in the market. First-party modules (0201 decision 3) and partner apps had no shared install and billing path. The owner answered these on 2026-10-25: the round-3 integration questions 5 to 7 and 11, and the OS questions OS-127, OS-128, OS-129, OS-217 and OS-382, with the round-9 pricing answer.

​
Decision

One provider, one Integration (round-3 #5).
  1. A provider is one Integration: one description, one Connection shape and one webhook route (0308 rules 1, 2 and 15). It plays one or more of five roles, declared on the Integration so the listing can show them:
    • driver: a capability we own calls it through a port (send a message, charge a card, store a file, clear an e-invoice). The port belongs to the package or OS service that owns the capability.
    • channel: a driver behind one notifications transport (mail, sms, whatsapp, push, inApp, chat, voice). Products declare channels, never providers (0223 decision 2).
    • surface: its host shows our tools, commands or cards (0348).
    • connector: it holds records we sync or starts our workflows, with triggers, actions and syncs (0218 decision 3).
    • webhooks: it sends us events, as WebhookEvent<I> on the same Integration, never a second route.
  2. Listed only when the tenant is involved. An Integration is listed in the app market only if a tenant connects it, consents to it or pays for it. An Integration whose only credential is the platform’s has a platform Connection and no listing.
  3. Slack (round-3 #6) is one Integration: the driver of the chat channel, the Slack app surface, and workflow triggers and actions.
  4. WhatsApp (round-3 #7) is its own channel transport, not a variant of SMS.
  5. Ad and social platforms (Commerce answers, Channels). Meta, TikTok, Snap and Google are one Integration each, covering the shop, the catalogue feed and tracking.
  6. Muslin’s connector catalogue (round-3 #11) becomes shared Integration listings; it is not kept as a second catalogue.
One app market (round 9).
  1. One app market holds first-party modules, partner apps and connector listings: one install flow, one bill, and an entitlement per module. A listing’s price stays a reference to an Entitlement (0308 rule 21). Developers.
  2. Open to any developer (OS-127). Anyone can create an app, integrate it and test it in developer sandboxes. A review step approves an app before it is listed. The registry carries the review state, developer sandboxes and the partner payout and fee-schedule records a product needs to bill partner apps on the tenant’s one invoice.
Settled by their recommended default (owner rule, default-applied.md).
  1. Tenant admins install modules per tenant; organisation admins may force-install or allow-list apps for child tenants (OS-122). Minor and patch versions auto-update; a major version or new permissions wait for admin consent (OS-123). Uninstall keeps the module’s data for a retention window, then deletes it with notice; legal holds win (OS-124). A disabled paid module is not billed from the next period (OS-125).
Figentra’s choices.
  1. Which connectors ship at launch and how they are priced, partner billing and fee schedules, the agency programme, listing prices, review rules, private apps, partner data-class limits, the developer portal and on-prem app bundles are Figentra OS ADRs 0037, 0038 and 0039 (owner round 22, 0259).

​
Consequences

  • A provider is described and listed once, whatever it does. Slack and Meta are not three listings each.
  • The market shows a tenant only what the tenant connects, consents to or pays for. Platform plumbing stays out of it.
  • One install flow and one invoice serve first-party modules and partner apps alike.
  • Developer sandboxes, a review queue and partner payout records must exist before the first partner app is listed.
  • The Activepieces piece format stays out of scope (0308 rule 21); only the publisher restriction changes.

​
Enforcement

planned — a roles declaration on the Integration (or derived by gen from the classes that bind it), checked by gen (STA-339/340); the listing schema in @stackra/integrations (today IntegrationListing holds only docsUrl); the OS registry and integrations services for the install flow, review queue and partner payouts.

​
Open questions

  1. Partner apps versus partner connectors. OS-127 opens app publishing to any developer; OS-217 keeps partner connectors for later. May a partner app declare its own Integration (its own provider credentials and webhooks) at launch, or only use first-party Integrations? Not decided.
  2. Shelves. Whether connector listings and apps are separate shelves inside the one app market is not decided.

​
Supersedes and sources

Supersedes: none. Amends, by Note: 0218 decision 5 and 0308 rule 21. Reads with 0201, 0214, 0274, 0348, 0356 and 0358. Sources: owner decisions in chat, 2026-10-25: round-3 questionnaire 5 to 7 and 11 (notes/handover/360/questionnaire-round-3.md); Commerce questionnaire Answers, Channels (360/questionnaire-commerce.md); OS rounds 9, 12, 15 and 22 (OS-127) and the defaults OS-122 to OS-125 (notes/handover/os/); the role rule of 360/integrations-and-marketplace.md section 1.3.