Opening the platform: the QuoxCORE Plugin SDK and Developer Marketplace

A plugin system without an SDK is a suggestion. A marketplace without a developer portal is a shop window with no door. This week, all three shipped.

Why platforms open up

QuoxCORE has had a plugin architecture since early on. JSON manifests, licence gating, sidebar registration, activation flows. The internal plugins work. But "we can build plugins" is a different statement from "you can build plugins."

The gap is tooling. Without an SDK, a developer has to reverse-engineer the manifest schema, guess at the build pipeline, and hope their output matches what the platform expects. Without a developer portal, there is no way to list what you have built. Without a marketplace, there is no way for users to find it.

All three shipped on 20 March. Here is what each one does.

The Plugin SDK

The SDK is a monorepo with three packages: a scaffolder, a types package, and a Vite build plugin. Run the scaffolder, pick a template, and you have a working plugin structure with manifest, build config, and test setup. No guesswork.

8 archetype templates:

The last two templates, specialist agent and agentic team, are the ones that matter most. They scaffold plugins that bring their own agents, following the pattern established by FORGE and KEEPER earlier that week. The agent manifest, tool declarations, sidebar registration, and AOCL policy bindings are all generated from the template.

The SDK also includes signing scripts. Every plugin submitted to the marketplace is signed, and the signature is verified at install time. This is not DRM. It is integrity verification. The user should know that the plugin they install is the plugin that was reviewed.

The Developer Portal (Stream 2)

The Developer Portal is where plugin developers register, manage their listings, and submit versions for review. It shipped as part of Stream 2 of the marketplace plan, alongside 41 tests.

One detail worth noting: the Developer Portal is itself a plugin. The Developer Tools plugin gates access to the seller dashboard. Activate the plugin, get access to the portal. This was a deliberate choice. The marketplace infrastructure eats its own cooking.

In-dashboard marketplace (Stream 3)

Stream 3 put the browse and install experience inside the dashboard. Users can discover plugins, read reviews, install free plugins with one click, and track what they have installed. Fifteen tests cover the install and review flows.

The commerce layer underneath

The marketplace needed a payment system. Stream SC (Subscriptions and Commerce) shipped the same day with Stripe integration: multi-item shopping cart with a slide-in drawer, subscription support, customer management, and a billing portal.

The store on quox.ai now has buy buttons on every product page, cart persistence across sessions, bundle overlap warnings (so you do not accidentally buy something twice), and admin tools for syncing products to Stripe with branded images. Eight audit fixes went into the commerce layer before it shipped, including fixing a mixed-cart bug and removing legacy pricing references.

Free plugins install directly. Paid plugins go through the cart. The checkout flow is Stripe-hosted, so we are not handling card details. Subscription management goes through Stripe's billing portal. The plumbing is straightforward because it should be.

The audit before the launch

Before the marketplace went public, it went through two rounds of security fixes: 7 HIGH-severity and 6 MEDIUM-severity issues. The fixes covered:

• Ownership checks on review CRUD operations (only the review author can edit or delete)
• Path containment on plugin downloads (no directory traversal)
• Status state machine enforcement (plugins cannot skip review states)
• Input validation on all marketplace endpoints
• Race condition handling on concurrent installs
• Pitch deck download path traversal fix
• Server-side seller filtering (not just client-side)

Fifty-six tests now cover the marketplace across four test files. The security audit was not a final step. It was baked into the development sequence: build, audit, fix, test, ship. That order matters when you are building something that handles other people's code.

The developer hub on quox.ai

The website's developer page was rewritten at the same time. The old version was a maze of links to different documentation sections. The new version is a single page: what the SDK is, how to scaffold a plugin, the 8 templates, how to submit, and where to find the docs. One page, no navigation required.

SDK archetype templates, store listings, and documentation pages all went live on the same day. A developer can go from "what is this" to "I have scaffolded a plugin" in one session, on one site, without being sent to a separate docs portal.

What this means for the platform

Three things shipped in the same week: the SDK, the Developer Portal, and the Marketplace. Together, they form the developer loop: build with the SDK, submit through the portal, publish to the marketplace, get installed by users.

That loop did not exist five days ago. The plugin system worked internally, but it was closed. Now it is open, with signing, review gates, install tracking, and a commerce layer. The next step is paid plugins with Stripe Connect revenue share, which is planned but not yet built. When it ships, developers will earn 75-80% on every sale.

Opening a platform is not a feature. It is a commitment. The SDK, the portal, and the marketplace are the first concrete evidence of that commitment. The architecture is there. The tooling is there. The door is open.

Quox (quox.ai) builds trust infrastructure for AI agent operations. Its open protocols, AEE for standardised agent messaging, AOCL for orchestration control and observability, and VOLT for cryptographic evidence chains, provide the accountability architecture that autonomous systems require. Four open protocol specifications. Building in the UK.