Skip to content

Integrations

ThinkWork integrations connect external apps and systems to the thread model. They ingest messages, webhooks, and events into threads, then let agents respond back through the same integration boundary.

This is the app and system side of Connectors: Slack, GitHub, Google Workspace, webhook-style inbound flows, outbound actions, and the auth and routing needed to make them work safely.

An integration typically does four jobs:

  1. Accepts an inbound event from an external system
  2. Validates auth, signatures, or OAuth state
  3. Creates or updates a thread in ThinkWork
  4. Sends agent or automation output back to the source system
External system event
→ API Gateway / connector endpoint
→ Connector handler
→ Thread created or resumed
→ Agent or automation runs
→ Response posted back to source system

Slack is the canonical chat integration.

Inbound

  • Direct messages and mentions become SLACK- threads
  • Connector metadata includes workspace, channel, user, and timestamp context
  • Routing rules can map channels or keywords to specialized agents

Outbound

  • Agents and automations can post replies, updates, and notifications back to Slack
  • Same thread context is preserved for auditability and follow-up turns

Setup requires a Slack app, OAuth scopes, and an Events API webhook endpoint.

GitHub integrations turn repository activity into operational work.

Inbound

  • Issues, pull requests, comments, and selected repository events become GH- threads
  • Mentions can explicitly summon an agent into an existing issue or PR flow

Outbound

  • Agents can comment, label, triage, review, and close work back in GitHub
  • Review actions stay tied to the originating thread for visibility

Typical auth uses a GitHub App with repository or organization installation.

Google Workspace covers productivity-system integrations.

Inbound

  • Gmail messages can create EMAIL- threads
  • Calendar events and reminders can trigger automations
  • Drive content can be referenced as part of knowledge and context flows

Outbound

  • Agents can reply to email, update calendar-related workflows, and participate in document-centric processes

Setup commonly uses OAuth 2.0, with tokens stored in the credential vault.

ThinkWork treats integrations as bidirectional by default.

PatternExample
Inbound messageSlack DM creates a support thread
Inbound webhookGitHub issue webhook creates a triage thread
Outbound replyAgent posts back to the Slack conversation
Outbound actionAgent comments on a pull request or replies to an email

This keeps the external system as the engagement surface while ThinkWork keeps the internal execution model.

Integrations usually need one of these auth patterns:

  • Webhook signing secrets for inbound validation
  • OAuth tokens for user or tenant-connected apps
  • Service credentials or API keys for system-to-system actions

ThinkWork stores integration credentials in the credential vault and resolves them only when the connector needs them.

When an integration creates a thread, it can attach source metadata and apply connector routing rules.

Common routing inputs include:

  • source system, such as Slack or GitHub
  • channel, repo, or mailbox
  • user identity
  • labels, keywords, or event type

This lets one integration fan work to different agents without changing the external app setup.

For systems beyond Slack, GitHub, and Google Workspace, ThinkWork supports custom connector recipes. A typical recipe includes:

  • an inbound handler
  • credential and auth configuration
  • routing rules
  • outbound tool definitions for responding back to the source system

See the Connectors authoring guide for the build pattern.