Choosing a path

You have an extension that builds and runs. This page decides where it goes. There are three destinations, they are told apart by what your users download, and the choice is reversible — the artifact you already have is the input to all three.

What your users download

	A · Marketplace extension	B · Branded desktop product	C · Your own product
They download	nothing new — they install your extension inside the WAMP they already run	your app, as its own installer, with its own name, icon and window	whatever you already ship; nothing of WAMP is visible
They need a WAMP install	yes	no — your binary is the install	no
You maintain	one extension	one extension plus a product file and a release feed	your product; WAMP is a dependency of your backend
Where the AI runs	in the user’s WAMP, on their account	in your binary, on whichever identity you configure	in your users’ clients, on tokens your backend mints
Distribution	the WAMP catalog	your own download page and update feed	your existing release channel

The questions that decide

Do your users already have WAMP? If they do, A is the whole job: one upload, and your extension appears in their catalog. If handing them a WAMP install is part of the pitch, you are choosing between B and C.

Is your extension a capability or the whole product? A capability composes — it wants the chat, the other extensions, the agents around it, and it is worth less on its own. A product wants its own window, its own name in the dock, and no WAMP chrome around it. That is the line between A and B, and it is expressed in a single field: a branded product sets rootPageId to one of your pages and boots straight into it.

Do you already have a server and a user directory? If yes, C. You are not looking for an app shell — you have one. You want metered model access with per-end-user attribution, which is exactly what an app principal gives you, and none of it requires shipping a desktop binary.

Who signs in is not a fourth path

The commonest mistake is to read “your app has its own users” as a separate way to ship. It is not. It is one key in the product file, valid on any branded build, and it does not change the extension at all.

accounts.mode	Who signs in	Other keys
wamp	a WAMP account. The product is a WAMP client, and everything platform-side — the marketplace, extension identity, the developer console — is available to it. This is the default when the key is absent	none accepted
none	nobody, and no account screen is ever shown. With an appSlug the product still uses app-attributed AI; without one it has no hosted AI at all. This is the shape of a tool you hand someone as a binary	appSlug optional
own	your users, in a directory hosted by WAMP but entirely separate from it. They have never heard of WAMP, cannot sign in to it, and their usage is attributed per person	appSlug required; signUp optional — whether a stranger may create an account or it is invite-only

The schema enforces the constraints in that last column: own without an appSlug fails the build, wamp with any other key fails the build, and signUp outside own fails the build. A product file is validated at build time, never at boot, so a mistake here is a build error rather than a broken install.

Your code never reads the mode. pluginAPI.auth answers “who is using this” in all three cases, which is why the same extension ships unchanged whichever identity the product is configured with. See Permissions for what auth exposes and Apps and credentials for what an appSlug is.

What is identical on every path

The extension. Same manifest, same permissions, same plugin API, same build. There is no “marketplace build” and no “product build” of your code — a branded product bundles the same staged artifact the catalog serves, so an extension you publish to the marketplace can also ship inside your own binary without a second version to maintain.

Paths also combine. B and C are not exclusive: a branded product with accounts.mode: 'own' and a developer who mints their own tokens are the same mechanism seen from two sides. In the first case WAMP holds the signing key; in the second you hold it. The AI proxy cannot tell the resulting tokens apart, so moving from hosted accounts to your own backend later is a matter of registering your own key — there is nothing to migrate. Your own backend covers both sides.

Where each path stands today

Read this before you commit to a path — the three are not equally finished.

A · Marketplace extension. Publishing works from a signed-in WAMP account, and the first account to publish a given slug owns it from then on. There is no publisher namespace, no review queue, and no version history: one listing per slug, and re-publishing is how you ship an update. Details and the exact upload contract are in Marketplace extension.

B · Branded desktop product. The product file, the build pipeline, and the release upload script all live inside the WAMP monorepo, so producing a branded binary requires access to that repository today. The macOS story additionally has two hazards worth knowing before you plan a release — both are documented in Branded desktop product.

C · Your own product. The server side is complete and the HTTP contract is stable, but @wamp/app-sdk is not published to npm, so today you either vendor the package or call the endpoints directly. The token you have to mint is a signed JWT with four claims, which is a short function in any language — see Your own backend for the contract and a worked example.

Not on this page

Running agents on WAMP’s own infrastructure rather than on a user’s machine — a durable session driven from a CRM, a bot, or a scheduler — is a separate product with its own documentation at docs.cloud.vampikez.fun. It is orthogonal to the three paths here: an extension, a branded product, and your own backend can each drive Cloud sessions.