Integrations Overview

Rensei Platform connects to third-party services - version control, issue tracking, deployment, and communication platforms - to power workflow automation and agent actions. Each integration exposes native-rich workflow nodes and handles credential management securely.

Integration categories

Integrations are grouped by functional domain:

Native-rich principle

Every integration adheres to the native-rich principle: workflow nodes and conditions expose the full native capability surface of the provider, not an abstracted subset. If a provider offers 50 distinct fields or operations, the integration offers all 50.

This means:

• No artificial limits - you can construct any API call the provider allows.
• Minimal learning curve - familiarity with the provider's API transfers directly to workflow authoring.
• Future-proof - new provider features are available in workflows immediately, without platform updates.

Conversely, abstraction layers are explicitly out of scope for integrations. Cross-provider, unified issue interfaces (e.g., "all issue trackers expose a common schema") are implemented at the workflow-editor level via generic action nodes and conditions, not in provider plugins.

Connect model

Integrations follow a standard connect, setup, and health pattern:

1. OAuth or credential entry

Most integrations offer OAuth 2.0 flows where supported (GitHub, Linear, Vercel), delegating authentication to the provider. Others require personal access tokens or API keys (Linear API key as fallback, Jira multi-field credentials).

• Navigate to Settings → Integrations
• Select the integration card
• Authorize or paste credentials
• Platform validates and stores encrypted credentials

2. Setup

On successful credential entry, the integration's setup() method runs:

• Validates the credential against the provider's API
• Returns a webhook URL and secret (if applicable)
• Stores metadata for the integration dashboard

For GitHub, you must manually configure the webhook URL in your repository's Settings → Webhooks to receive push/PR/CI events.

For Linear and Vercel, webhook subscriptions are auto-managed by the platform - no manual step required.

3. Health checks

The platform periodically calls healthCheck() to ensure the credential is still valid. If it fails:

• Integration is marked unhealthy in the settings UI
• Workflow nodes using the integration fail gracefully with diagnostic error messages
• Operators see actionable alerts in the admin console

4. Teardown (optional)

Removing an integration triggers teardown(), which may revoke webhooks or remove subscription records.

Workflow nodes and conditions

Every integration exposes native workflow nodes - one per provider action or query. For example:

• GitHub: branch.create, pr.create, pr.merge, file.read, check-run.create, plus triggers
• Linear: issue.create, issue.update, comment.create, issue status/assignee/priority conditions, plus triggers
• Jira: issue.create, issue.update, comment.add, transition, plus custom field mutation nodes

Nodes live in the workflow editor's node palette, grouped by integration, and are available only if the integration is connected.

See individual integration pages (e.g., /docs/integrations/linear) for the full node reference.

Credential scoping and resolution

Credentials are stored at the workspace level but resolved at dispatch time based on the workflow's context:

1. If a workflow specifies a credential reference (e.g., "use GitHub credential X"), the platform resolves it from the credential store.
2. If the credential is expired or invalid, the work item fails with a descriptive error.
3. Multi-field credentials (Jira: { site, email, apiToken }) are resolved on-demand by action handlers; they do not serialize into the daemon environment snapshot.

For agent workflows, credential resolution happens at the start-of-session injection phase, ensuring the agent has the right API tokens available locally.

Webhook security

All inbound webhooks (GitHub, Linear, Vercel, Incident.io, GitHub Actions) are validated via HMAC signatures:

• Signature header: x-hub-signature-256 (GitHub/Vercel), Authorization: Bearer <signature> (Linear), provider-specific (Incident.io)
• Verification: HMAC-SHA256 with the webhook secret provisioned during integration setup
• Idempotency: Redis-backed deduplication prevents duplicate work items on webhook retries
• After-defer: Synchronous validation happens before enqueuing work, so invalid signatures are rejected immediately

Refer to individual integration pages for webhook setup details.

Feature flags and gradual rollout

Some integrations are feature-flagged and require operator enablement:

• GitHub Issues: Feature-flagged - requires GitHub App installation and must be enabled by your Rensei operator.
• Partial integrations (GitLab tracker, Bitbucket tracker): Marked as coming-soon in the UI until full implementation is complete.

Check the status banner on each integration page for current support level.

Integration limitations and partial support

Not all integrations are at feature parity. Refer to the status matrix below:

Next steps

• GitHub - Branches, PRs, commits, and CI status
• Linear - Issues, comments, workflows, and agent sessions
• Jira - Multi-field issue tracking
• Vercel - Deployment events and preview URLs
• Slack - Outbound incident notifications