Publishing to the Marketplace

Before you submit

• Confirm workspace eligibility and accept the Publisher Agreement.
• Publish the exact version you tested and document its functionality and upgrade behavior.
• Complete the listing, support contact, privacy policy, and terms of service.
• Demonstrate why every requested scope and event subscription is necessary.
• Complete the testing preflight and security review.
• Name an operational owner who will monitor errors and respond to customer and Throttle review messages.

Eligibility

Your workspace must meet both of the following conditions before you can submit an extension for review:

Listing requirements

Before submitting for review you must complete your extension's public listing. The preflight check validates all of the following fields. Missing or invalid fields are returned as an array of specific errors with a 422 response.

• Public name — a human-readable display name for the marketplace listing, separate from the internal extension slug.
• Tagline — a single sentence (≤ 80 characters) that describes what the extension does.
• Category — one of the marketplace taxonomy categories (e.g. analytics, fulfillment, finance). Displayed as a filter on the browse page.
• Icon — a square PNG or SVG uploaded via the icon-upload flow. Stored as a public S3 object and referenced by its public URL.
• At least one screenshot — a minimum of one screenshot or promotional image (PNG/JPEG, 1280 × 800 recommended). Used in the detail page carousel.
• Support URL — an HTTPS URL to a support page or ticketing system.
• Privacy policy URL — an HTTPS URL to your privacy policy. Required by the Publisher Agreement.
• Terms of service URL — an HTTPS URL to your extension's terms of service.

Review lifecycle

Submitting for review kicks off an automated preflight followed by a manual staff review. The full state machine is:

stateDiagram-v2
  [*] --> not_submitted: Private extension with a published version
  not_submitted --> pending: Developer submits for review
  pending --> in_review: Staff claims the review
  in_review --> approved: Staff approves
  in_review --> changes_requested: Staff requests changes
  in_review --> rejected: Staff rejects
  changes_requested --> pending: Developer resubmits
  approved --> public: Developer clicks "Publish to marketplace"

1. Submit — call POST /api/v1/extensions/:id/reviews (or use the dashboard Review tab). Throttle runs automated preflight checks (listing completeness, eligibility, scope diff against the previous approved version) and creates a review with status pending. A confirmation notification and email are sent to workspace members with the extensions:write scope.
2. In review — a Throttle staff member claims the review. The review moves to in_review. Staff can see the automated check results and the scope delta relative to the previously approved version.
3. Decision — staff selects one of three outcomes:
   • Approved — the extension passes review. The developer receives a notification and email and can now publish the extension.
   • Changes requested — staff adds feedback in a threaded conversation. The developer receives a notification with the feedback, addresses the issues, and resubmits.
   • Rejected — the extension will not be published to the public marketplace. Staff includes a reason. The developer may fix the underlying issues and submit a new version for review.

# Submit the latest published version of your extension for review.
# Requires: an accepted Publisher Agreement + a completed Listing.
curl -X POST https://api.usethrottle.dev/api/v1/extensions/ext_xxx/reviews \
  -H "Authorization: Bearer <dashboard-session>" \
  -H "content-type: application/json" \
  -d '{}'
# Response:
# {
#   "data": {
#     "id": "rev_01HZX...",
#     "extensionId": "ext_xxx",
#     "status": "pending",
#     "versionId": "ver_xxx",
#     "createdAt": "2026-06-06T10:00:00.000Z"
#   }
# }

What “Approved” unlocks

An approved review does not automatically make your extension public. Approval unlocks the Publish to marketplace button in the dashboard Lifecycle tab and the POST /api/v1/extensions/:id/lifecycle endpoint with lifecycle: "public". You choose when to go live.

# Once the review is approved, the developer publishes the extension.
curl -X POST https://api.usethrottle.dev/api/v1/extensions/ext_xxx/lifecycle \
  -H "Authorization: Bearer <dashboard-session>" \
  -H "content-type: application/json" \
  -d '{ "lifecycle": "public" }'
# → { data: { id: "ext_xxx", lifecycle: "public", ... } }

• Once public, the extension appears in GET /api/v1/extensions?installable=true and is browsable in the marketplace at /w/:ws/a/:app/marketplace.
• You can revert to private at any time via the lifecycle endpoint. Existing installs are not affected by a lifecycle change.
• Setting the lifecycle to private automatically publishes a version snapshotting the current configuration when no published version matches it, so a private extension is always immediately installable. Installing an extension that somehow has no published version fails with 409 no_published_version.
• Throttle retains the ability to revert a public extension to private in the event of a policy violation (takedown — Phase 2).

Future versions and re-review

After your extension is public, you can publish new versions at any time. Not all updates require a new review:

Launch and rollback

• Choose a staffed launch window and verify listing assets immediately before publishing.
• Run a small, non-destructive production smoke test and monitor setup, event delivery, and provider errors.
• Keep support contacts and incident ownership current on the listing.
• If the extension is materially degraded, move the listing private to stop new installs while you communicate with existing installers.
• Lifecycle changes do not silently upgrade or remove existing installs; handle compatibility and migration explicitly.

After launch, follow the operations guide for monitoring, incidents, support, and retirement.

Webhook events

The review pipeline emits four webhook events in the extension.review.* family. Subscribe to them on any workspace webhook endpoint with the extensions:read scope. See the Webhooks reference for the full payload shapes.

• extension.review.submitted — fired when the developer submits a review.
• extension.review.approved — fired when staff approves the review.
• extension.review.changes_requested — fired when staff requests changes; data.feedback contains the message.
• extension.review.rejected — fired when staff rejects the review; data.feedback contains the reason.

Related guides

• Extensions Overview — lifecycle model, surfaces, versioning.
• Extension Versioning — create and publish versions before submitting for review.
• Extension Scopes — which scopes an extension may request.
• Webhooks — full event catalog and payload reference.