Reference

Integration action reference

Every provider and action supported by the unified integration surface, plus the separate repository-native VCS boundary.

The unified integration domain supports six providers — slack, github, notion, linear, jira, and figma — plus all for applicable cross-provider reads. The provider connection and the authenticated user's access still determine what can be returned.

Use this page when constructing a direct call. For the human workflow, see Connecting GitHub, Slack, and the rest.

Provider values

ValueConnected product
slackSlack
githubGitHub knowledge/integration data
notionNotion
linearLinear
jiraJira
figmaFigma
allApplicable cross-provider reads

Action matrix

ActionProviderPurpose
statusAny providerConnection and sync status
connectedUse all; the action always reads all providersList connected integrations
searchAny provider or allSearch provider content
statsAny provider or allCounts and activity statistics
activityAny provider or allRecent provider activity
contributorsAny provider or allContributor activity
knowledgeAny provider or allRetrieve provider-backed knowledge
summaryAny provider or allSummarize a bounded date range
channelsslackList/search channels
discussionsslackRetrieve channel threads and discussions
sync_usersslackRefresh Slack user mappings
reposgithubList/search connected repositories
issuesgithub, linear, or jiraQuery issue records with provider filters
filesfigmaList/search Figma files
create_pagenotionCreate a Notion page
search_pagesnotionSearch Notion pages
get_pagenotionRead one Notion page
update_pagenotionUpdate a Notion page
create_databasenotionCreate a Notion database
list_databasesnotionList Notion databases
query_databasenotionQuery a database with filters and sorts
team_activityAny provider or all, in team modeAggregate connected activity for the team
team_searchUse all, in team modeCross-provider team search

Frequently used fields include query, limit, since, until, days, and workspace_id, but each action consumes only its compatible subset. The complete field map below makes those boundaries explicit.

Slack

Slack supports the common read actions plus channels, discussions, and sync_users. Use search for matching messages and discussions when thread structure and replies matter. A connected workspace does not grant access to channels the connected Slack account cannot read.

Code
integration(provider="slack", action="search", query="rate-limit decision")
integration(provider="slack", action="discussions", query="billing")

GitHub

GitHub supports the common reads, repos, and issues. Use the separate vcs domain when you need repository-native detail or mutation: pull request diffs, comments, checks, reviews, merges, issue creation/updates, commits, branches, tags, trees, blobs, notifications, links, automations, webhooks, or repository ingest.

Code
integration(provider="github", action="issues", query="timeout")
vcs(provider="github", action="get_pull_diff", repo_ref="owner/repo", number=42)

The integration domain covers connected product knowledge. The VCS domain is the operational repository API.

Notion

Notion has the broadest provider-specific surface:

  • Page reads: search_pages, get_page
  • Page writes: create_page, update_page
  • Database reads: list_databases, query_database
  • Database writes: create_database

Page content is Markdown. Depending on the operation, use page_id, parent_page_id, parent_database_id, database_id, title, content, properties, filter, and sorts. Supported content types are NotionTask, NotionMeeting, NotionWiki, NotionBugReport, NotionFeature, NotionJournal, and NotionPage.

Writes should identify the intended parent explicitly. Do not infer a database or page from a similarly named search result.

Linear and Jira

Both support common reads and issues.

ProviderIssue filters
Linearteam_id, status, priority, assignee
Jiraproject_key, status, priority, issue_type, assignee

Jira issue_type accepts the installation's names, commonly Bug, Story, Task, or Epic. These integration actions query connected issues; they are not the same records as ContextStream's native entity(kind="ticket", …) objects.

Figma

Figma supports the common reads plus files. Narrow file listings with figma_project_id. The schema currently accepts file_key, but no public integration action consumes it; do not infer a single-file read operation from that field. Figma is a knowledge/search integration here, not a design-file editing API.

Team-wide actions

team_activity and team_search require team mode and a team-capable account. They aggregate only providers and records the caller is authorized to see. Choosing team mode changes the execution scope; it does not widen the underlying provider permissions.

Complete input field map

FieldsUsed for
provider, actionRequired routing values
workspace_idOptional workspace scope
query, limitSearch text and result bounds where supported
days, since, untilSummary, statistics, activity, and team-activity windows
node_type, max_tokensKnowledge filtering and summary size
database_id, page_id, parent_page_id, parent_database_idNotion object and parent selection
title, content, properties, descriptionNotion page/database content and metadata
filter, sortsNotion database queries; each sort has property and direction
event_type, status, priority, has_due_date, tagsNotion page-search filters
team_id, assigneeLinear issue filters
project_key, issue_typeJira issue filters
figma_project_idFigma file-list filter
project_id, file_keyAccepted by the current schema but not consumed by a public action

Fields omitted by an action are not universal filters merely because the consolidated schema accepts them. Generate requests from the current tools/list schema and this action map.

ChatGPT and other clients

ChatGPT is a client surface, not an integration provider value. Connect it through the supported ChatGPT gateway or custom MCP flow described in ChatGPT and desktop apps. GitLab and Bitbucket likewise belong to the separate vcs provider list, not this integration enum.