2,100+ app integrations, MCP servers and databases
In short
Integrations give a workflow or agent access to 2,100+ app integrations, 11,800+ actions and 3,300+ triggers, plus databases, data warehouses and any Model Context Protocol server. A credential is either an organization-owned Connection shared across a project, or a per-user account each end user of a deployed App links themselves. Every action call is traced like any other node, so what an agent did in a third-party app is auditable after the fact.
What Integrations does
- A single action catalog
- Send a Gmail message, post to Slack, update a CRM record and more, across 2,100+ app integrations with 11,800+ actions.
- Triggers from any connected app
- Fire a deployed App from 3,300+ triggers across the same catalog, a new Slack message or an incoming email among them.
- MCP servers as tools
- Point an agent at any Model Context Protocol server and every tool it exposes becomes an individual agent tool automatically.
- Databases and warehouses
- Query PostgreSQL, MySQL, Snowflake and Redshift directly (Databricks SQL from the SDK), or reach a private database through an SSH tunnel.
- Org connections or per-user
- Share one connection across a whole project, or require each end user of a deployed App to link their own account.
- Every credential encrypted
- Secrets are stored server-side and never embedded in a workflow definition; a workflow references a connection only by its id.
One catalog, three ways to use it
An Action tool runs one operation of one app: search the catalog, pick an action such as sending a Gmail message or updating a CRM record, and the tool's schema is generated for you, with any field you fill in at build time made optional for the model to override. The same catalog powers triggers, so an App event trigger can start a run when a new message lands in a channel or a form is submitted, and AI Coworker's connectors give it the same apps for one conversation at a time. Across all three, Dynamiq connects to 2,100+ app integrations with 11,800+ actions and 3,300+ triggers.
- Add all actions on an app row to hand the agent its whole surface at once
- Some fields load their options live from the linked account, such as a Slack channel list
- A failed action with a 400, 401, 402 or 422 status comes back as an observation the agent can react to
MCP servers
Model Context Protocol is the open standard for exposing a tool server to an agent. Add an MCP Streamable HTTP or MCP SSE connection with the server's URL and any auth headers it needs, attach an MCP Server tool to an agent, and at initialization the node asks the server which tools it offers and turns each one into a typed agent tool automatically. Include or exclude specific tool names to keep a large server's surface from crowding out everything else in the agent's prompt.
- Schemas are discovered at run time, so a server's new tools appear without a workflow change
- Servers that only support interactive OAuth need a local stdio bridge; token auth works directly
- A tool call that fails comes back to the agent as a recoverable observation, not a run failure
Server URL
https://mcp.servicing.internal/mcp
Headers
Authorization: Bearer ••••••••
- search_policies
- get_customer
- create_case
- list_open_cases
Organization connections and per-user connections
Most integrations belong to a project and are shared by whatever runs there, an LLM provider key, an internal database, a service account nobody wants to reauthorize per user. Some actions have to run as the person using the product instead, reading their inbox or posting to their own workspace. Flag that node as a requirement and each end user of a deployed App authorizes their own account once, through a hosted page or your own UI, kept completely separate from every other user's connection.
- A single workflow can mix a shared Connection for its LLM with a per-user requirement for one action
- AI Coworker's own connectors are a third, separate system: personal or organization-wide, used only inside a conversation
- Deleting a source or a connection removes what it authorized; nothing lingers for another user to inherit
- Mark an integration optional, so end users connect only the apps they choose through scoped connect links
Organization
Per user
Apps your agents can act in
Enterprise systems teams connect first
Salesforce
61 actions · 12 triggers
HubSpot
109 actions · 27 triggers
Zoho CRM
12 actions · 9 triggers
Pipedrive
41 actions · 6 triggers
Microsoft Dynamics 365 Sales
12 actions · 15 triggers
Workday
10 actions · 1 triggers
QuickBooks
65 actions · 10 triggers
Xero Accounting
39 actions · 4 triggers
ServiceNow
28 actions
Zendesk
33 actions · 10 triggers
Freshdesk
57 actions · 4 triggers
Freshservice
11 actions · 4 triggers
Intercom
13 actions · 16 triggers
Microsoft Teams
12 actions · 6 triggers
Microsoft Outlook Email
26 actions · 4 triggers
Sharepoint
23 actions · 5 triggers
Microsoft OneDrive
11 actions · 2 triggers
Microsoft Entra ID
12 actions
Google Workspace Admin
4 actions · 4 triggers
Gmail
21 actions · 5 triggers
Google Drive
50 actions · 17 triggers
Google Sheets
38 actions · 8 triggers
Google Calendar
17 actions · 6 triggers
Google Docs
23 actions · 2 triggers
Slack
50 actions · 9 triggers
Zoom
25 actions · 14 triggers
Twilio
24 actions · 5 triggers
Calendly
12 actions · 4 triggers
Jira
39 actions · 4 triggers
Confluence
11 actions · 3 triggers
Asana
23 actions · 14 triggers
Trello
35 actions · 14 triggers
monday
16 actions · 10 triggers
ClickUp
52 actions · 7 triggers
Airtable
18 actions · 8 triggers
Linear
17 actions · 6 triggers
Notion
25 actions · 9 triggers
Smartsheet
28 actions · 4 triggers
Miro Developer App
14 actions · 3 triggers
Snowflake
9 actions · 14 triggers
Databricks
42 actions
PostgreSQL
9 actions · 5 triggers
MySQL
10 actions · 5 triggers
MongoDB
9 actions · 4 triggers
Upstash Redis
2 actions
GitHub
48 actions · 27 triggers
GitLab
16 actions · 10 triggers
AWS
23 actions · 11 triggers
Datadog
13 actions · 1 triggers
PagerDuty
31 actions · 2 triggers
Amplitude
11 actions
Segment
7 actions · 1 triggers
Stripe
48 actions · 11 triggers
Docusign
13 actions · 2 triggers
Shopify
57 actions · 8 triggers
Box
19 actions · 3 triggers
Dropbox
19 actions · 3 triggers
Typeform
15 actions · 1 triggers
Okta
4 actions · 1 triggers
Auth0 (Management API)
0 actions · 1 triggers
Mailchimp
30 actions · 13 triggers
Greenhouse
7 actions · 3 triggers
BambooHR
8 actions
Catalog categories
- Productivity
- Communication
- Developer tools
- Cloud
- Monitoring
- Analytics
- Security
- Database
Where teams use it
- Back-office and finance operationsReconcile accounts, clear payment exceptions, prepare dispute cases and draft reports across the systems you already run, with approval before anything commits.
- Accounts payable and invoicesRead invoices, match them to purchase orders and receipts, route exceptions and prepare payments, with approval before anything posts or pays.
- Customer serviceAnswer inbound calls and chats, look up and act on the account, and hand complex cases to a person, with every conversation traced.
Works with
- Agent BuilderDesign an agent on a visual canvas or in the open-source Python SDK. Both compile to the same engine, so what you build ships either way.
- Apps and deploymentsDeploy a saved workflow version as an App with its own hostname. Call it over HTTP, embed a chat widget, or trigger it on a schedule or an event.
- KnowledgeA knowledge base converts your documents into searchable context: ingestion, chunking, embedding and storage, managed for you or pointed at your own vector store.
Questions and answers
How many apps can a Dynamiq agent act in?
2,100+ app integrations are in the catalog, with 11,800+ actions and 3,300+ triggers across them, covering productivity, communication, developer tools, cloud, monitoring, analytics, security and database apps.
What is an MCP server?
Model Context Protocol is an open standard for a tool server an agent can call. Connect one over Streamable HTTP or SSE, and every tool it exposes becomes an individual agent tool, discovered automatically rather than defined by hand.
What is the difference between an organization connection and a per-user connection?
An organization connection is shared credentials every run in a project uses, set up once by a builder. A per-user requirement instead has each end user of a deployed App authorize their own account, kept separate from every other user's.
Can an agent reach my own database?
Yes. PostgreSQL, MySQL, Snowflake and Redshift connections are available directly, Databricks SQL from the SDK, and a database on a private network can be reached through an SSH tunnel to a bastion you expose.
Are integration credentials stored safely?
Secrets are encrypted server-side and never embedded in a workflow definition. A workflow references a connection by its id only, and rotating a credential updates every node that uses it without a redeploy.
See an agent on your own workflow.
Bring a process and its documents. Our engineers will show you how Dynamiq runs it, in your environment or ours.