Marketplace guide
How the Marketplace works.
Everything listed here was built on a Data Pod and published from it — and what you build on yours can be too.
Installing
Three doors, one result. Whichever you use, the package is applied by your own pod, under your pod's own rules.
One click, from this website
Signed in with a Data Pod linked to your Synap account, Project templates and Workspaces install straight from their page. Your account vouches for you to your pod with a short-lived signed handoff — this site never holds your pod's credentials.
In the Synap app
“Open in Synap” opens the app with the install filled in. You confirm it there. This works for most kinds, and for pods that are not linked to an account.
From your terminal
The CLI installs into whichever pod it is connected to — the same door, the same confirmation.
synap market install <slug>
If your pod reviews changes before they land, an install arrives as a proposal. Nothing is added until you approve it.
Publish a project
A project already knows which workspaces it uses. Ask your agent, connected through the Synap connector, to publish it: it exports the project pack — the workspaces and the project's playbooks — and publishes it as one installable template.
Publish my <project name> project to the Synap Marketplace.It publishes structure, not your data. Records, documents and messages stay on your pod. To publish a single workspace from your terminal, use the command below.
Your running Workspace is the package.
synap market publish --from-workspace <id>There is no manifest to write describing the app you built. You point at the app you are already running — its data model, its Views, its Automations, its playbooks, its onboarding — and it is serialized into something installable.
Author, validate, publish, install.
Four commands, and the last three are the same whether the package is a Capability you wrote by hand or an entire Workspace you have been living in for a month.
Scaffold. A starting file for a Workspace template, or a Card or View package. Capabilities are authored directly — by hand, or by your agent — rather than scaffolded.
synap market scaffold <slug>Validate. Checks the declaration against the schema for its kind, so the failure lands on your machine rather than on someone else's pod.
synap market validate <file>Publish. One catalog, one write door. The package gets a version, and the version is what other pods install.
synap market publish <file>Install. On the receiving pod the package becomes real: a Workspace arrives as an actual surface with its own dock row in the Browser, not a document describing one.
synap market install <slug>
You, or your agent. Your agent can author a package on your pod and, connected through the Synap connector, publish it. From the terminal, the CLI publishes a file or a single workspace.
Package kinds
A Project template is a Workspace package that requires other workspaces — so under the hood there are six kinds. Their status is stated plainly: what works end to end, and what nobody has published yet.
Workspace
A whole app: data model, Cards, Views, Automations and its onboarding — declared as one file.
Publishing one serializes a Workspace you are already running — see the loop above.
Capability
A credentialed tool your agent can call — the API key stays in your pod.
View
A way of looking at entities — board, calendar, gallery, bento.
Installs on the pod today; the CLI cannot install one yet.
Automation
A repeatable triggered process — each execution is an inspectable run.
The loop works end to end; nobody has published one yet.
Card
How one entity renders — and how a View renders, and what sits in a bento.
Rendering code from a package runs in a sandboxed frame that reaches only the origins the package declares — you see them before you approve the install. Nobody has published one yet.
Skill
A verb your agent knows. Skills ride inside a Capability today.
Standalone Skills have no schema yet; publish one inside a Capability.
Entity kinds, roles, property definitions, playbooks and agents are not published on their own. They travel inside a Workspace, which is part of why a Workspace is the interesting unit: it is the only package that carries a whole working model rather than one piece of it.
Installing does not hand over the keys.
An installed Workspace brings Automations, and its Capabilities hold credentials — so the question is what they are allowed to do. The answer is the same one that governs your own agent: consequential writes arrive as proposals you approve. You see the change before it becomes true, whoever authored the package.
No package carries a “Verified” badge and nothing is ranked by install count: neither is a signal an outsider can trust, so the Marketplace does not pretend they are. How governance works