SupaProxy is built on a plugin architecture. Every extension point follows the same pattern: an interface definition, a registry for auto-discovery, a config schema that the dashboard renders dynamically, and an npm package that bundles the built-in implementations.Documentation Index
Fetch the complete documentation index at: https://docs.supaproxy.cloud/llms.txt
Use this file to discover all available pages before exploring further.
Plugin types
Consumers
Entry points where users interact with the AI. Slack, API, and custom integrations.
@supaproxy/consumersConnections
Data sources the AI can call. HTTP, STDIO, and authenticated MCP transports.
@supaproxy/connectionsProviders
AI model providers. Anthropic, OpenAI, and custom LLM backends.
@supaproxy/providersKnowledge Sources
External content ingested into workspace context. URLs, Confluence, inline text.
@supaproxy/knowledge-sourcesHow it works
Every plugin type follows the same lifecycle:Interface
Each plugin type defines a TypeScript interface. The interface specifies the methods the server calls and the config schema the dashboard uses to render forms.Registry
Each package exports a registry object that maps plugin types to their implementations. The server imports the registry and looks up plugins by type at runtime.Config schema
Every plugin defines its configuration as a Zod schema. The dashboard reads this schema via the API and renders form fields dynamically. Adding a new plugin with new config fields requires zero dashboard changes.Packages
| Package | Purpose | Built-in plugins |
|---|---|---|
@supaproxy/consumers | User-facing entry points | Slack, API |
@supaproxy/connections | MCP transport and auth | HTTP, STDIO, Authenticated |
@supaproxy/providers | AI model backends | Anthropic, OpenAI |
@supaproxy/knowledge-sources | Content ingestion | URL, Confluence, Inline |

