Scrydon
Integrations

Custom Integrations

Build, bundle, and deliver 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 — deliver it through a pack source, install it from your org's pack catalog, 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 publish it in a pack.

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.

Publish the bundle in a pack to a Git/OCI source, then register that source under Settings > Platform > Integrations > Custom and install it from your org's pack catalog. 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)                  │
└─────────────────┬───────────────────────────────────────┘
                  │ Deliver via a pack source (Git/OCI)

┌─────────────────────────────────────────────────────────┐
│  Platform Runtime                                       │
│                                                         │
│  Manifest Catalog ── metadata (what blocks/tools exist) │
│  SandboxActor ────── execution (Worker Thread per org)  │
│  Policy Engine ───── governance (capability allowlists) │
└─────────────────────────────────────────────────────────┘

Key Concepts

ConceptPurpose
VendorTop-level container — metadata, auth config, and one or more products
ProductA grouping unit that gets enabled/disabled per organization
ToolRuntime logic — Zod-validated input/output with an execute() function
BlockWorkflow editor UI — form fields (subBlocks), data flow (inputs/outputs)
CapabilityOptional runtime interfaces — LLM, STT, TTS, Embedding, Video, OCR, Webhooks, Discovery
ManifestAuto-generated JSON metadata — the platform reads this without loading your code
SandboxActorIsolated 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 globalsprocess, Bun, Deno are 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 install time rejects malformed bundles
On this page

On this page