Vendors

The integration catalog — every vendor, the products they expose, and the capabilities they contribute

A vendor is a third-party (or first-party) system Scrydon talks to — Google, OpenAI, Salesforce, Mistral, the built-in scrydon core, and so on. Every block, tool, and runtime capability you can use in a workflow is exposed by a vendor.

The model is always the same: Vendor → Product → Capabilities (tools, blocks, triggers, runtime capabilities). There is no flat global tool catalog. If you don't see what you need here, you can author your own integration and upload it.

The model

Vendor                    e.g. google, openai, scrydon
└── Product               e.g. gmail, sheets, drive — one per vendor area
      ├── Block           workflow-editor card (one per product)
      ├── Tools           individual operations the agent can call
      ├── Triggers        webhook + polling triggers
      └── Capabilities    runtime contracts: LLM, STT, TTS, embeddings, image, video, OCR, webhooks, discovery

A workflow that "sends a Gmail" is using vendor=google → product=gmail → tool=send-mail. The "Gmail" card on the canvas is google → gmail → block. The platform's integration registry resolves all of this — you never hardcode vendor names in workflow code.

Catalog

Built-in (always available)

Scrydon

Platform-native products: Knowledge, Memory, Storage, Tables, Workflow, Web, Search, SSH, SMTP, SMS, Guardrails, A2A, Generic, Core.

Productivity & Storage

Google

Workspace + public APIs: Gmail, Sheets, Docs, Drive, Calendar, Search, Translate, YouTube, +11 more.

Microsoft

Microsoft 365: Excel, OneDrive, Outlook, Planner, SharePoint, Teams, Resource Discovery.

Atlassian

Jira, Confluence, Bitbucket Cloud — issues, wiki, source control.

GitHub

Repositories, issues, pull requests, files, gists, workflows, releases, milestones, projects, search, webhooks.

Salesforce

CRM: accounts, contacts, leads, opportunities, cases, reports, SOQL.

Microsoft Dynamics 365

Customer Engagement, Business Central, Finance & Operations.

SAP S/4HANA

Read and write SAP S/4HANA Cloud business data via OData.

AI & LLMs

Anthropic

Claude Opus, Sonnet, and Haiku via the Messages API.

OpenAI

GPT family + embeddings, image / video generation, STT, TTS, vision.

Mistral

Chat, embeddings, Document AI (OCR), and Voxtral audio.

Azure AI Foundry

Per-org deployed LLMs, embeddings, images, audio.

AWS Bedrock

Foundation models via the Converse API.

Ollama

Local open-source LLMs and embeddings.

vLLM

Self-hosted high-throughput inference.

Cloud

Google Cloud

BigQuery, Cloud Storage, Pub/Sub, Vertex AI, Speech, Vision, Translate, +5 more.

Where vendors come from

Source	What it produces
First-party templates in `packages/sdk-authoring/src/integrations/templates/`	The vendors on this page — shipped with the platform.
Custom integrations built with the Integrations Authoring SDK	Uploadable `.bundle.tar.gz` archives that register a new vendor at runtime. No platform redeploy.

Both paths produce the same kind of artifact (a defineVendor() definition); the only difference is where the bundle is stored.

Capability resolution (LLM, STT, TTS, embeddings, …)

Capabilities are resolved through the integration registry, in this order:

Per-call override (e.g., a block setting that pins one model)
Org policy (defaults configured by an admin)
Automatic pick across installed candidates (first that matches the requested capability)
null — callers translate this to HTTP 412 ("no provider configured")

Capabilities resolve through your installed integrations — no vendor is hardcoded and no silent fallback occurs. Speech-to-text requests are brokered server-side by the platform (credentials never leave the server); other capabilities (LLM, embedding, OCR) resolve through your installed integrations at request time. Never import a vendor SDK directly in product code, never hardcode a vendor branch, never silently fall back to a vendor the org didn't install.