First-Party App Connectors
Relevant source files
The following files were used as context for generating this wiki page:
- packages/twenty-apps/twenty-slack/package.json
- packages/twenty-apps/twenty-linear/package.json
- packages/twenty-codex-plugin/references/concepts/how-apps-work.md
- packages/twenty-codex-plugin/references/publish-app/prepare-for-app-store.md
- packages/twenty-codex-plugin/references/develop-app/app-structure.md
- packages/twenty-codex-plugin/references/develop-app/standalone-pages.md
First-party app connectors in Twenty are standalone npm packages designed to extend a Twenty instance with specific third-party integrations (e.g., Slack, Linear). These connectors are modular extensions that plug into the core platform, adding new objects, fields, and logic tailored to the integrated service. Unlike external services, these connectors run within the Twenty environment, leveraging the Twenty SDK to interact with workspace data and UI.
These apps are built using a standardized structure that includes entity definitions for data modeling, front components for user interface, and logic functions for automation. They are installed per workspace and can be synchronized or published to a marketplace for broader distribution.
Sources: packages/twenty-codex-plugin/references/concepts/how-apps-work.md, packages/twenty-apps/twenty-slack/package.json
Architecture and Core Components
First-party connectors follow a strictly defined architecture to ensure compatibility with the Twenty server and front-end rendering engine.
The Extension Model
A connector is a standalone package that does not run its own server. Instead, it is "installed" into a running Twenty instance. The instance loads the app's metadata and entities into its schema.
The diagram above illustrates how a connector app synchronizes its definitions into a target Twenty instance.
Sources: packages/twenty-codex-plugin/references/concepts/how-apps-work.md:10-22
Required SDKs
Every connector app relies on two primary SDK packages to interface with the platform:
| Package | Role | Key Functionality |
|---|---|---|
twenty-sdk | Entity Definition | Registration of apps, objects, fields, and roles via twenty-sdk/define. |
twenty-client-sdk | Data Access | Querying workspace records via CoreApiClient. |
Sources: packages/twenty-codex-plugin/references/concepts/how-apps-work.md:24-42
Data Model and Logic
Connectors extend the Twenty data model by declaring new entities that represent data from the third-party service.
Entity Definitions
Connectors use defineEntity or specific wrappers like defineObject and defineField to contribute to the workspace schema. For example, a Slack connector might define a "Slack Channel" object linked to a Twenty "Company".
- Universal Identifiers (UUIDs): Every entity must have a stable UUID v4 that survives renames and version updates.
- Logic Functions: Used for side effects, such as posting a message to Slack when a deal is closed in Twenty.
Sources: packages/twenty-codex-plugin/references/concepts/how-apps-work.md:118-124, packages/twenty-codex-plugin/references/develop-app/app-structure.md:14-22
Logic and Connection Providers
First-party apps often implement Connection Providers to manage OAuth setup for third-party services. This allows users to securely link their external accounts directly from the Twenty settings.
Sequence of establishing an OAuth connection via a first-party connector.
Sources: packages/twenty-codex-plugin/references/publish-app/prepare-for-app-store.md:38-48
Front Component Rendering
Connectors provide custom UI through "Front Components." These are rendered inside an isolated Remote DOM container within the Twenty workspace.
Constraints and Capabilities
Front components have specific operational boundaries to ensure security and performance:
- No Global Access: Components cannot access
windowordocumentdirectly. - SDK UI: They must use UI primitives from
twenty-sdk/uito maintain visual consistency. - Application Variables: Connectors can use non-secret application variables to customize behavior without hardcoding values.
Sources: packages/twenty-codex-plugin/references/concepts/how-apps-work.md:88-103, packages/twenty-codex-plugin/references/develop-app/standalone-pages.md:162-175
Standalone Pages
For full-page experiences (e.g., a Slack message log or a Linear issue board), connectors define STANDALONE_PAGE layouts.
| Component | Description |
|---|---|
definePageLayout | Sets the type to STANDALONE_PAGE and defines the widget grid. |
defineNavigationMenuItem | Places the app in the sidebar using NavigationMenuItemType.PAGE_LAYOUT. |
Sources: packages/twenty-codex-plugin/references/develop-app/standalone-pages.md:18-35
Development and Deployment Workflow
The lifecycle of a connector app follows a Create -> Develop -> Sync -> Validate loop.
- Syncing: Developers use
yarn twenty dev --onceto build and push entity definitions to a target remote Twenty instance. - Versioning: Every packaged deploy requires a strictly higher semver version in
package.json. - Remotes: Connections to different Twenty instances (Local, Staging, Production) are managed as "remotes" in the local CLI config.
Sources: packages/twenty-codex-plugin/references/concepts/how-apps-work.md:68-85, packages/twenty-codex-plugin/references/develop-app/app-structure.md:73-85
Summary
First-party app connectors like twenty-slack and twenty-linear are the primary mechanism for extending Twenty's core CRM capabilities with external integrations. By utilizing a shared SDK and a unified entity registration model, these connectors ensure that third-party data and logic behave as native parts of the Twenty workspace. They balance deep integration with security through isolated front-component rendering and stable universal identification of data entities.