DocsPlugin Development
Free
Plugin Development
How the plugin catalog is structured, how a plugin gets injected into generated code, and what a custom plugin looks like under the hood. Reference for power users; not a self-service path today.
Anatomy of a Plugin
Each plugin is a single JSON manifest under api/plugins/definitions/{name}.json plus an entry in registry.json. The manifest declares:
- category: one of the 15 platform categories (payments, auth, database, etc.).
- configFields: what users fill in when enabling the plugin (API keys, region, custom URLs).
- promptTemplate: a snippet injected into the AI prompt at generation time, telling the model how to use this service.
- codeSnippets: optional concrete code examples the AI can reference for tricky patterns.
- detection: keyword and code-pattern hints used to auto-suggest the plugin from a prompt.
Detection & Injection
1
Detection
On every prompt, the platform scans for plugin keywords and code-pattern hints. Matches surface as suggestions; users accept or dismiss.
2
Generation
Active plugins inject their
promptTemplate + codeSnippets into the AI prompt, so the generated code uses the right SDK, import paths, and API patterns.3
Code injection
Static plugin code (SDK loaders, helper functions) is wrapped in HTML comment markers and inserted into the generated app. On every code save, the marker block is stripped and re-inserted so injection is idempotent.
Backend-secret plugins (Stripe, OpenAI) inject server-side patterns so secret keys never end up in client-side JavaScript. Detection considers this and routes the right injection target.
Why Not Self-Service Yet
A plugin runs in the prompt context of every generation. A poorly written plugin can confuse the AI on every app it touches, leak secrets, or generate insecure patterns at scale. We currently land plugins through the platform team to control that blast radius.
The platform has 80+ plugins. If your need fits one of them, use it. If it does not, the next-best path is a Function or Custom Handler with your own code.
Alternatives
- For a one-off third-party call, write a Function.
- For a co-located webhook receiver or form processor, use a Custom Handler.
- For platform-level instruction ("always wire integration X this way") across many apps, create a Skill.
- For automation that chains multiple steps, use a Workflow.
Skills + Functions cover most use cases people reach for "custom plugin" about. Try those before requesting a catalog addition.
FAQs
Can I author my own plugin and ship it with my app?▾
The plugin catalog is platform-managed today (the 80+ plugins under api/plugins/definitions). User-defined plugins are not in scope for self-service. If you need custom integration code, write a Function or a custom handler instead; either gives you the same outcome without needing platform changes.
How would I propose a new plugin?▾
File a request describing the third-party service, the configFields users would fill in, the prompt template you want injected, and the code snippets that should appear in generated code. Plugins that cover well-known services with stable SDKs are the easiest to land.
Where does plugin code go in my generated app?▾
Plugins inject their code (SDK loads, environment variable hooks, helper functions) wrapped in HTML comment markers <code><!-- GenMB Plugins START/END --></code>. On every code save, the platform strips the marker block and re-injects fresh, so plugin code is idempotent and never duplicated.
Ready to build?
Create your first app for free, no credit card required.