Skip to content
threada Docs

Marketplace follow-on setup and support

This guide gives customers, reviewers, and operators one public setup and support reference for the second-wave Threada marketplace targets that are not yet backed by individual public app packages.

This is a launch-control guide, not evidence that the listed marketplace apps, commercial offers, partner accounts, or public listings have been approved. Use the sections below as the public setup_support_docs reference for the marketplace evidence tracker until a marketplace has its own package-specific setup guide.

Current status

All marketplaces in this guide are public launch follow-ons. Some providers already have a runtime-bound v1 workflow inside Threada, but Threada must not claim public marketplace availability for any listed provider until the real provider account, production app or listing configuration, approved install or purchase flow, Secret Manager credential references, tenant mapping, reviewer-safe smoke test, submission materials, and approval evidence are captured outside the repository.

Secrets, cookies, raw exports, reviewer credentials, customer data, private tenant payloads, and screenshots containing private tenant data must never be committed to the repository or pasted into public documentation.

Shared setup requirements

Every marketplace in this guide needs the same baseline before public launch:

  • A Threada-owned provider, developer, partner, seller, or publisher account.
  • A production app, integration, connection, listing, offer, or package ID.
  • OAuth, SSO, signed webhook, approved install, or marketplace acquisition flow configured with production HTTPS URLs.
  • Secret Manager or approved external evidence references for credentials, webhook secrets, signing keys, OAuth client secrets, marketplace API credentials, and product/listing IDs.
  • Tenant, workspace, organization, account, repository, board, service, or billing-account mapping inside Threada.
  • Clear setup-required, connected, approval-pending, succeeded, failed, disconnected, and uninstalled states.
  • Reviewer-safe smoke evidence for install or purchase, mapping, one v1 workflow, failure handling, disconnect or cancellation, and cleanup.
  • Public support email or support URL, privacy URL, terms URL, security or data-handling notes, reviewer instructions, and listing assets.

Intercom App Store

Status: workspace-keyed runtime-bound OAuth integration implemented; public App Store launch still planned. A private config scaffold exists at packages/intercom-marketplace-app for a public OAuth app posture using Developer Hub write_tickets permission only. No real Intercom Developer Hub public app, production reviewer evidence, review submission, or App Store approval has been observed.

Enterprise-safe v1: create a governed Intercom ticket from an approved Threada action using the shared marketplace OAuth install path. Keep conversation read/sync, conversation note, tag, reply, close, Messenger Canvas, Inbox Canvas, and other inbox automation behavior out of v1 until those flows are implemented, runtime-bound, and approved.

Setup and support: bind the installed Intercom workspace, identified from OAuth /me app.id_code, to a Threada tenant, pack, queue, or workspace mapping. The setup flow must show the connected workspace, configured Threada destination, OAuth status, disconnect behavior, and the exact ticket-write plus workspace-identity data shared with Threada.

Reviewer smoke: install the public app in a reviewer-safe Intercom workspace, authorize Threada, map the Intercom workspace to a Threada destination, approve one governed action that creates a test Intercom ticket, verify setup-required, failure, and disconnect states, and capture sanitized evidence.

Do not claim: conversation sync, autonomous inbox agents, bulk conversation export, user export, campaign automation, broad teammate/admin access, or generic Intercom automation.

Okta Integration Network

Status: runtime action, admin credential install, and Studio setup handoff live. Studio exposes https://studio.threada.ai/integrations/okta/install to preload the Okta connector preset and runtime integration kind. Authenticated Threada tenant admins can install an Okta-managed org API token through POST /api/v1/integrations/okta/directory-install. No real OIN Wizard submission, verified app, public catalog listing, diagnostics evidence, or OIN approval has been observed. Identity-provider publication remains blocked; tenant sign-in supports IdP-initiated SAML configured directly in Admin.

Enterprise-safe v1: the governed, approval-gated okta_upsert_user action through the runtime connector. Identity-provider marketplace publication, SCIM, Universal Logout, entitlement management, Workflows Connector, and lifecycle management remain blocked until their exact runtime behavior, lifecycle tests, and customer admin docs are implemented and verified.

Setup and support: start from https://studio.threada.ai/integrations/okta/install when configuring the runtime-bound Okta action path for a pack. The current admin credential install path accepts resource_key as the Okta-managed org domain, for example dev-123456.oktapreview.com; endpoint_url as the matching org origin, for example https://dev-123456.oktapreview.com; and credential.api_token (aliases: okta_api_token or token) as the bare API token without an SSWS prefix. The BFF stores an okta_api_token_v1 payload in Secret Manager and upserts a tenant-scoped INTEGRATION_TYPE_OKTA integration with okta_upsert_user as both the capability set and marketplace action allowlist.

Reviewer smoke: install a reviewer-safe Okta org API token, bind the connector to a pack, approve an okta_upsert_user proposal, verify the resulting user mutation and auditable execution record, then exercise a denied or invalid credential path and capture sanitized diagnostics.

Do not claim: broad Okta admin automation, custom-domain API-token install, identity-provider marketplace sign-in, SCIM provisioning, packaged Workflows Connector behavior, public OIN approval, or catalog listing readiness until those flows are implemented and approved.

GitHub Marketplace

Status: planned. A private launch-control scaffold exists at packages/github-marketplace-app for a public GitHub App and Marketplace listing posture. Runtime action binding exists through INTEGRATION_TYPE_GITHUB, but no real GitHub App, Marketplace listing, runtime smoke evidence, installation mapping, webhook smoke evidence, billing plan, or Marketplace approval has been observed.

Enterprise-safe v1: GitHub App that creates or links a governed Threada WorkItem from an issue, pull request, discussion, or repository event.

Setup and support: bind the installed GitHub organization or repository installation to a Threada tenant, pack, queue, or workspace mapping. Setup must document app permissions, webhook events, setup URL, callback behavior, uninstall cleanup, and support contacts.

Reviewer smoke: install the GitHub App in a reviewer-safe organization or repository, complete the setup URL, receive and verify one webhook event, create or link one WorkItem, verify uninstall cleanup, and capture sanitized webhook and UI evidence.

Do not claim: broad repository contents access, organization admin access, secret/workflow/package access, repository write automation, code scanning, or Marketplace billing readiness until those exact flows are implemented and reviewed.

Notion Marketplace

Status: partially implemented. Runtime Notion page creation, the shared workspace-keyed OAuth install path, and a private launch-control package at packages/notion-marketplace-app exist. No public Notion Marketplace approval, reviewer database mapping evidence, or public connection listing approval has been observed.

Enterprise-safe v1: Notion connection that creates a governed Notion page from a reviewed Threada action using the insert_content capability on an explicitly shared database.

Setup and support: the OAuth callback binds the installed Notion workspace to the Threada tenant by Notion workspace_id; setup must then map an explicitly shared database to the intended Threada pack, queue, or workspace. Runtime execution requires that database mapping and rejects payloads that target a different mapped database. Setup must explain that Threada can access only authorized content and must show disconnect and permission-revocation behavior.

Reviewer smoke: install the connection in a reviewer-safe Notion workspace, share one test database, map it to Threada, create one governed Notion page from reviewer-safe Threada data, verify revoked access behavior, disconnect, and capture sanitized evidence.

Do not claim: broad workspace export, unbounded page crawling, private page access, database query/sync, schema mutation, user export, packaged knowledge sync, or generic Notion automation.

Asana App Directory

Status: partially implemented. Runtime Asana task creation, a workspace-keyed OAuth install path, and a private launch-control package at packages/asana-app-directory-app exist. No public Asana app approval, App Directory submission, reviewer workspace/project evidence, or listing approval has been observed.

Enterprise-safe v1: Asana app that creates a governed Asana task from a reviewed Threada action using only workspaces:read for OAuth workspace discovery and tasks:write for task creation.

Setup and support: OAuth binds the selected authorized Asana workspace GID to the Threada tenant. Optionally bind a selected project to a tenant, pack, queue, or workspace mapping. Runtime execution requires the OAuth workspace binding and rejects payloads that target a different mapped workspace or configured project. Setup must document OAuth scopes, workspace sharing, disconnect behavior, field mapping, and support paths.

Reviewer smoke: authorize a reviewer-safe Asana workspace, map one project, create one governed Asana task from reviewer-safe Threada data, verify setup-required and disconnect behavior, and capture sanitized evidence.

Do not claim: workspace export, portfolio/admin automation, project creation, bulk task mutation, webhook ingestion, or packaged Asana knowledge sync until those flows are implemented and reviewed.

monday.com Marketplace

Status: partially implemented. Runtime monday.com item creation, the board-keyed shared OAuth install path, and a private launch-control package at packages/monday-marketplace-app exist. No public monday.com Marketplace app approval, share link, reviewer board mapping evidence, or approval has been observed.

Enterprise-safe v1: monday.com app that verifies the selected board and group, then creates a governed monday.com item from a reviewed Threada action using the boards:read and boards:write OAuth scopes.

Setup and support: bind the installed monday.com app to a selected board before OAuth starts, and optionally bind a selected group, to a Threada tenant, pack, queue, or workspace mapping. Runtime execution requires the board mapping and rejects payloads that target a different mapped board or configured group. Setup must document app permissions, feature locations, disconnect, and support contacts.

Reviewer smoke: install the app by share link or reviewer path, map one test board, create one governed monday.com item from reviewer-safe Threada data, verify setup-required and disconnect behavior, and capture sanitized evidence.

Do not claim: broad account export, admin automation, board-wide mutation, column or automation management, private API-token public install, webhook ingestion, packaged knowledge sync, or generic monday.com automation.

AWS Marketplace

Status: internal commercial marketplace procurement ingestion is live for the aws_marketplace IntegrationType, and the private AWS package at packages/aws-marketplace-app now emits the technical configuration, listing metadata, required asset checklist, readiness report, and reviewer smoke test. Provider-side AWS Marketplace seller registration, SaaS product listing, fulfillment-adapter callback configuration, private-offer flow, reviewer smoke evidence, and publication approval are still planned follow-ons and have not been observed.

Enterprise-safe v1: SaaS contract or subscription listing for Threada with marketplace acquisition routed to governed tenant provisioning.

Setup and support: provider-verified AWS acquisition, entitlement, subscription, private-offer, and cancellation events must call the signed Threada procurement callback with the mapped Threada tenant header, marketplace buyer, entitlement, product, paid plan, lifecycle status, and source event ID. That records subscription metadata and an auditable billing event; the signed public BFF procurement callback now handles normalized AWS events, while the provider listing must still prove AWS-side entitlement verification, idempotency, buyer onboarding, support handoff, legal links, and cancellation behavior.

Reviewer smoke: complete a reviewer-safe subscription or private offer, resolve entitlement, provision a Threada tenant or billing account, verify cancellation or entitlement-change behavior, and capture sanitized evidence.

Do not claim: AWS Marketplace availability, private offers, procurement, metering, entitlement sync, or buyer onboarding until seller registration, offer configuration, and smoke evidence exist.

Microsoft Commercial Marketplace

Status: internal commercial marketplace procurement ingestion is live for the microsoft_marketplace IntegrationType, and the private Microsoft package at packages/microsoft-commercial-marketplace-app now emits the Partner Center offer metadata, listing metadata, required asset checklist, readiness report, and reviewer smoke test. Microsoft Partner Center SaaS offer approval, offer ID evidence, landing page or fulfillment-adapter callback evidence, certification evidence, reviewer smoke evidence, and marketplace approval are still planned follow-ons and have not been observed.

Enterprise-safe v1: Microsoft commercial marketplace SaaS offer for Threada with marketplace acquisition routed to tenant provisioning.

Setup and support: provider-verified Microsoft commercial marketplace activation, plan change, suspension, and cancellation events must call the signed Threada procurement callback with the mapped Threada tenant header, marketplace buyer, entitlement, product, paid plan, lifecycle status, and source event ID. That records subscription metadata and an auditable billing event; the signed public BFF procurement callback now handles normalized Microsoft events, while the marketplace landing page and provider listing must still prove activation, plan changes, suspension, cancellation, support contact, privacy URL, terms URL, and idempotency behavior.

Reviewer smoke: acquire the SaaS offer in a reviewer-safe path, activate the subscription, provision a tenant or billing account, test plan-change or cancellation behavior, and capture sanitized fulfillment evidence.

Do not claim: AppSource or Azure Marketplace SaaS availability, subscription lifecycle support, private plans, or commercial certification until Partner Center review passes.

Google Cloud Marketplace

Status: internal commercial marketplace procurement ingestion is live for the google_cloud_marketplace IntegrationType, and the private Google Cloud package at packages/google-cloud-marketplace-app now emits the product configuration metadata, listing metadata, required asset checklist, readiness report, and reviewer smoke test. Google Cloud Marketplace partner listing, SaaS product approval, fulfillment-adapter callback evidence, entitlement smoke evidence, reviewer smoke evidence, and approval are still planned follow-ons and have not been observed.

Enterprise-safe v1: Google Cloud Marketplace SaaS listing for Threada with marketplace procurement routed to tenant provisioning.

Setup and support: provider-verified Cloud Marketplace order, account, entitlement, and cancellation events must call the signed Threada procurement callback with the mapped Threada tenant header, marketplace buyer, entitlement, product, paid plan, lifecycle status, and source event ID. That records subscription metadata and an auditable billing event; the signed public BFF procurement callback now handles normalized Google Cloud events, while the provider listing must still prove entitlement verification, idempotency, buyer onboarding, support, privacy, terms, and data handling.

Reviewer smoke: complete a reviewer-safe procurement or test acquisition, resolve entitlement, provision the Threada tenant or billing account, verify entitlement-change and cancellation behavior, and capture sanitized evidence.

Do not claim: Google Cloud Marketplace availability, procurement, entitlement sync, metering, or buyer onboarding until partner account, SaaS listing, integration, and review evidence exist.

Oracle Cloud Marketplace

Status: internal commercial marketplace procurement ingestion is live for the oracle_cloud_marketplace IntegrationType, and the private Oracle package at packages/oracle-cloud-marketplace-app now emits listing configuration metadata, marketplace listing metadata, required asset checklist, readiness report, and reviewer smoke test. Oracle Partner Network or Partner Portal listing evidence, application or service listing approval, provider handoff/acquisition callback evidence, reviewer smoke evidence, and approval are still planned follow-ons and have not been observed.

Enterprise-safe v1: Oracle Cloud Marketplace service or application listing for Threada with marketplace interest or procurement routed to sales-assisted tenant provisioning.

Setup and support: provider-verified Oracle Marketplace inquiry, lead, procurement, or customer handoff events must call the signed Threada procurement callback with the mapped Threada tenant header, marketplace buyer or handoff identifier, entitlement, product, paid plan, lifecycle status, and source event ID when the event represents a billable procurement state. That records subscription metadata and an auditable billing event; the signed public BFF procurement callback now handles normalized Oracle events, while the provider listing must still prove support routing, privacy, terms, buyer handoff, and idempotency behavior.

Reviewer smoke: submit or preview the listing through the partner path, exercise the customer handoff or acquisition flow, provision a reviewer-safe tenant or account, verify support escalation, and capture sanitized evidence.

Do not claim: Oracle Cloud Marketplace availability, OPN approval, buyer procurement, or automated provisioning until partner and listing review evidence exist.

Datadog Marketplace

Status: runtime action live; public Marketplace listing planned. The private Datadog package at packages/datadog-marketplace-app now emits listing metadata, the Studio setup install URL, runtime binding, data-sharing disclosure, required asset checklist, readiness report, and reviewer smoke test. No Datadog Partner Network approval, Marketplace offering, dashboard or monitor assets, reviewer smoke evidence, or approval has been observed.

Enterprise-safe v1: existing governed Datadog event posting through a tenant-scoped runtime integration, then a packaged Datadog integration that surfaces Threada operational metrics or events and links incidents or WorkItems back to Threada.

Setup and support: start from https://studio.threada.ai/integrations/datadog/install, which preloads the Datadog connector preset and runtime integration kind in Studio, then bind the Datadog org, API-key Secret Manager reference, and selected event surface to a Threada tenant monitoring or export profile. Setup must document credentials, least-privilege permissions, dashboards, disconnect, support, and data retention.

The runtime install path is implemented for authenticated tenant admins at POST /api/v1/integrations/datadog/directory-install. Submit resource_key as the stable Datadog org key, optional display_name, optional endpoint_url limited to Datadog API hosts, and credential.api_key (aliases: dd_api_key or token). The BFF writes the credential payload to Secret Manager, then upserts a tenant-scoped Datadog runtime integration with datadog_post_event as the marketplace action allowlist. The console-shell runtime client exposes this as installMarketplaceDirectoryCredential.

Reviewer smoke: install the integration in a reviewer-safe Datadog org, connect a Threada tenant profile, emit one test metric/event or link one WorkItem, verify uninstall behavior, and capture sanitized evidence.

Do not claim: broad org/admin access, log export, monitor mutation, paid Marketplace offering, or observability automation until partner and review evidence exist.

PagerDuty Integrations Directory

Status: runtime action live; public directory presence planned. The private PagerDuty package at packages/pagerduty-integrations-directory-app now emits listing metadata, the Studio setup install URL, runtime binding, data-sharing disclosure, required asset checklist, readiness report, and reviewer smoke test. No partner submission, directory listing, service integration guide approval, reviewer smoke evidence, or publication approval has been observed.

Enterprise-safe v1: PagerDuty integration that triggers or links a governed PagerDuty incident from a Threada WorkItem or approved alert workflow.

Setup and support: start from https://studio.threada.ai/integrations/pagerduty/install, which preloads the PagerDuty connector preset and runtime integration kind in Studio, then bind the PagerDuty account, service integration, and routing-key Secret Manager reference to a Threada tenant, pack, queue, escalation policy, or workspace mapping. Setup must document event/API credential handling, incident field mapping, disconnect, support, and cleanup.

The runtime install path is implemented for authenticated tenant admins at POST /api/v1/integrations/pagerduty/directory-install. Submit resource_key as the stable PagerDuty service key, optional display_name, optional endpoint_url limited to https://events.pagerduty.com/v2/enqueue, and credential.routing_key (aliases: integration_key or service_key). The BFF writes the credential payload to Secret Manager, then upserts a tenant-scoped PagerDuty runtime integration with pagerduty_trigger_incident as the marketplace action allowlist. The console-shell runtime client exposes this as installMarketplaceDirectoryCredential.

Reviewer smoke: configure a reviewer-safe PagerDuty service, map it to Threada, trigger or link one test incident, verify setup-required and cleanup behavior, and capture sanitized evidence.

Do not claim: account/admin automation, schedule mutation, escalation-policy mutation, unmanaged API-key install, or broader on-call automation until implemented and approved.

Discord App Directory

Status: runtime-bound with admin credential install, but not listing-ready. Runtime Discord webhook intake and signature verification exist, authenticated tenant admins can install Discord app credentials through the marketplace directory install path, and the private Discord package at packages/discord-app-directory-app now emits listing metadata, the Studio setup install URL, runtime binding, data-sharing disclosure, required asset checklist, readiness report, and reviewer smoke test. No Developer Portal app binding, App Directory discovery profile, reviewer smoke evidence, or approval has been observed.

Enterprise-safe v1: Discord slash command or message command that creates a governed Threada WorkItem from a server or user-installed context.

Setup and support: start from https://studio.threada.ai/integrations/discord/install, which preloads the Discord connector preset and runtime integration kind in Studio, then bind the installed Discord server or user context, public-key/bot-token Secret Manager reference, and channel permissions to a Threada tenant, pack, queue, or workspace mapping. Setup must document install contexts, command permissions, data handling, uninstall, and support.

The runtime install path is implemented for authenticated tenant admins at POST /api/v1/integrations/discord/directory-install. Submit resource_key as the stable Discord guild or user-install context key, optional display_name, optional endpoint_url limited to https://discord.com/api/v10, and credential.public_key plus credential.bot_token (public-key aliases: application_public_key or discord_public_key; bot-token alias: token). The BFF writes the credential payload to Secret Manager, then upserts a tenant-scoped Discord runtime integration with discord_signed_webhook_intake discord_bot_message_reply as the marketplace capability set. The console-shell runtime client exposes this as installMarketplaceDirectoryCredential.

Reviewer smoke: install the app in a reviewer-safe Discord server, execute one slash or message command, create one WorkItem, verify setup-required and uninstall behavior, and capture sanitized evidence.

Do not claim: broad message history access, moderation/admin access, member export, unsolicited direct messages, or generic Discord automation.

Evidence references

For launch tracking, record this guide or the relevant anchor in the setup_support_docs gate for the corresponding marketplace in .deploy-evidence/marketplace-program-evidence.json. Replace the reference with a package-specific setup guide only after that marketplace has a real production app, listing, install path, and reviewer-safe smoke evidence.

Use:

task marketplace:program -- evidence-status \
  --evidence .deploy-evidence/marketplace-program-evidence.json \
  --json-out .deploy-evidence/marketplace-program-status.json \
  --markdown-out .deploy-evidence/marketplace-program-status.md

The status command must remain red until every required gate for every marketplace is implemented with sanitized evidence references. Required non-Slack marketplaces also remain red until a launch-control package descriptor exists and is bound to a real runtime IntegrationType or WebhookProvider.