Custom Integrations
Build, bundle, and upload custom vendor integrations using the Scrydon Integrations SDK
The Scrydon Integrations SDK lets you build custom vendor integrations as self-contained bundles. Each bundle is a .tar.gz archive containing compiled code and a manifest — upload it through the Settings portal and it becomes available in the workflow editor immediately.
No monorepo access or platform redeployment required. Install the SDK from NPM, write your integration in TypeScript, build, and upload.
Integrations bring vendor capability into the platform. Shipping domain content (an ontology + workflows + a process flow) instead? That's a Pack — see Packs & Authoring SDK.
How It Works
Every integration follows the same lifecycle:
Use the SDK's defineVendor(), defineProduct(), defineTool(), and defineBlock() helpers to declare your integration in TypeScript. Zod schemas validate inputs and outputs at both build time and runtime.
Run sdk-authoring integrations build to compile your TypeScript into a single ESM bundle, extract a manifest with JSON Schema representations of your Zod schemas, and package everything into a .bundle.tar.gz.
Upload the custom integration through Settings > Platform > Integrations > Custom (or via the API). The platform validates the manifest, stores the artifact, and registers it in the catalog.
When a workflow uses your tool, the platform spins up a sandboxed Worker Thread for your bundle. Your execute() function runs in isolation with injected credentials, a logger, and execution context.
Architecture
┌─────────────────────────────────────────────────────────┐
│ Your Code (TypeScript) │
│ │
│ defineVendor({ auth, products: [ │
│ defineProduct({ block, capabilities: { │
│ tools: [ defineTool({ input, output, execute }) ] │
│ }}) │
│ ]}) │
└─────────────────┬───────────────────────────────────────┘
│ sdk-authoring integrations build
▼
┌─────────────────────────────────────────────────────────┐
│ Bundle (.tar.gz) │
│ ├── manifest.json (metadata, JSON Schemas, UI def) │
│ ├── dist/index.js (compiled ESM, all deps inlined) │
│ └── assets/ (icons, optional) │
└─────────────────┬───────────────────────────────────────┘
│ Upload via Settings UI or API
▼
┌─────────────────────────────────────────────────────────┐
│ Platform Runtime │
│ │
│ Manifest Catalog ── metadata (what blocks/tools exist) │
│ SandboxActor ────── execution (Worker Thread per org) │
│ Policy Engine ───── governance (capability allowlists) │
└─────────────────────────────────────────────────────────┘Key Concepts
| Concept | Purpose |
|---|---|
| Vendor | Top-level container — metadata, auth config, and one or more products |
| Product | A grouping unit that gets enabled/disabled per organization |
| Tool | Runtime logic — Zod-validated input/output with an execute() function |
| Block | Workflow editor UI — form fields (subBlocks), data flow (inputs/outputs) |
| Capability | Optional runtime interfaces — LLM, STT, TTS, Embedding, Video, OCR, Webhooks, Discovery |
| Manifest | Auto-generated JSON metadata — the platform reads this without loading your code |
| SandboxActor | Isolated Worker Thread per org per vendor — no cross-tenant state leakage |
Security Model
All bundles — including first-party integrations — run through the same sandboxed execution path:
- Worker Thread isolation — no access to the host process, filesystem, or other tenants
- Restricted globals —
process,Bun,Denoare not available in the sandbox - Credential injection — your code receives tokens via
ctx.auth, never handles raw secrets - Policy enforcement — organization policies control which capabilities and vendors are allowed
- Manifest validation — Zod schema validation at upload time rejects malformed bundles
Getting Started
Build your first integration in 5 minutes with the hello-world example
SDK Reference
Complete API reference for defineVendor, defineTool, defineBlock, and more
Capabilities
Add LLM, STT, TTS, embedding, webhooks, and discovery to your vendor
Uploading
Upload bundles via the Settings UI or API, and manage installed integrations