Availability
| Edition | Deployment Type |
|---|---|
| Community & Enterprise | Self-Managed, Hybrid |
Architecture
Single Responsibility
Each plugin should have a clear, focused purpose:- ✅ UI + PostAuth for rate limiting dashboard
- ✅ PostAuth + Response for request/response correlation
- ✅ Object Hooks + UI for approval workflows
- ❌ Unrelated features that could be separate plugins
BasePlugin Usage
Always useBasePlugin for consistent lifecycle management:
Expandable
Configuration Management
Parse configuration inInitialize(), validate early:
Expandable
Error Handling
Fail Fast, Fail Clearly
Return errors early with descriptive messages:Expandable
Log Errors with Context
Always include relevant context in error logs:Graceful Degradation
Don’t fail hard if non-critical operations fail:Performance
Minimize Blocking Operations
Avoid blocking in request path:Expandable
Use Connection Pooling
Reuse HTTP clients and database connections. The SDK provides aDefaultHTTPClient() with sensible defaults (30s timeout, connection pooling, TLS handshake timeout):
http.NewRequestWithContext(ctx, ...) to respect context cancellation and timeouts. Never use the default http.Client{} with zero timeout in production plugins.
Cache Frequently Accessed Data
Use KV storage or in-memory caching:Expandable
Batch Operations
Batch external calls when possible:Security
Input Validation
Always validate and sanitize inputs:Expandable
Least Privilege Permissions
Only request permissions you actually need:Expandable
Secrets Management
Never hardcode secrets, use configuration:Sanitize Logs
Don’t log sensitive data:Observability
Structured Logging
Use key-value pairs for searchable logs:Expandable
Request Tracing
Include request IDs for correlation:Expandable
Metrics Collection
Track plugin performance:Expandable
Testing
Unit Tests
Test plugin logic in isolation:Expandable
Integration Tests
Test with Service API:Expandable
Object Hooks Best Practices
Hook Priority
Use priority to control execution order:- 0-10: Critical validation (security, compliance)
- 11-50: Business logic validation
- 51-100: Enrichment and metadata
Before vs After Hooks
Usebefore_* hooks for:
- Validation that can block operations
- Required field checks
- Security policy enforcement
- Approval workflows
after_* hooks for:
- Notifications
- Audit logging
- External system sync
- Non-blocking enrichment
Metadata Storage
Use PluginMetadata for tracking:Multi-Capability Patterns
Shared State
Share data structures between capabilities:Expandable
State Persistence
Use KV storage for durable state:Expandable
Deployment
Version Management
Use semantic versioning:- MAJOR: Breaking changes (incompatible API changes)
- MINOR: New features (backward-compatible)
- PATCH: Bug fixes (backward-compatible)
Resource Cleanup
Always clean up inShutdown():
Expandable
Health Checks
Implement health check methods:Expandable
Common Pitfalls
AUTH Plugins: App Linking Requirement
The most common AUTH plugin pitfall is not linking credentials to App objects. A valid credential alone is insufficient—the system needs the App context for access control. Why This Matters: Apps provide the access control context that governs what authenticated requests can do:- Policy enforcement (rate limits, quotas)
- Tool and datasource permissions
- LLM access restrictions
- Budget controls
AuthHandler interface:
Expandable
-
HandleAuthreturns a validAppIdthat exists in the database -
HandleAuthreturns a validUserIdthat exists in the database -
GetAppByCredentialfetches the complete App object via Service API -
GetUserByCredentialfetches the complete User object via Service API - The App has the required permissions for the tools/LLMs the user needs
1. Modifying Shared Data Without Locking
Expandable