How connectors work
Synap syncs data from Nango, an OAuth and sync platform. You authorize a connection (currently: Google) through Nango’s OAuth flow — brokered through the control plane by default (it never sees your data, only the OAuth handshake) so no per-pod OAuth app setup is required, or through a self-hosted Nango instance if you run your own. Your pod then pulls data from the external service, classifies it into the appropriate entity profiles, and stores it locally.
This architecture is intentional. Your pod pulls data rather than having external services push to it, and the sync process goes through the same permission and event chain system as any other write. The first sync of a newly connected service is never silent — it produces one grouped review for you to approve before anything lands; after that, whether later syncs land automatically or need another review is a setting you control per connection.
Currently supported connectors
Google (Calendar + Gmail + Contacts)
One connection, one OAuth flow. Calendar events sync as event entities (start/end dates, location, attendees) and open back in Google Calendar with an “Open in Google Calendar” action on the entity. Contacts sync as person entities. From Gmail, Synap links the people and companies you correspond with — mail threads themselves are not stored or opened in Synap yet.
The sync model in detail
The sync process follows these steps:
- You connect an external service in the Connectors settings panel
- Nango handles the OAuth flow and stores the access/refresh tokens securely
- Your pod is notified (by the control plane, or directly if self-hosted) and pulls data from the external service
- Each item is classified into the appropriate entity profile
- The first sync of a connection is grouped into a single proposal for you to review and approve — never a silent bulk write
- Approving it with “keep syncing automatically” left on means later syncs apply directly; turning it off routes every future sync back through a review, and either choice is changeable anytime
Sync cadence depends on the connection and provider activity — triggered on connect, periodically, and when the provider notifies of a change — rather than a fixed interval per connector.
Connector data as regular entities
Once synced, connector data is indistinguishable from manually created entities. A Google Calendar event is a regular event entity. This means you can:
- Search across local and synced data with the same search bar
- Display synced entities in any view type (table, kanban, calendar, bento)
- Link synced entities to other entities (connect a contact to a deal, relate a meeting to a project)
- Include synced entities in AI conversations and let the AI reason about them
Governance and the event chain
Connector syncs go through the same event chain as AI mutations. Every synced item creates an event in the immutable audit log. If a connector sync creates incorrect data, you can see exactly what happened in the event chain and roll back individual items. The proposal system can be configured to require approval for connector writes, giving you a review gate for external data before it enters your workspace.
Future connectors
The connector architecture is designed for extensibility — adding a new sync source is mostly configuration (declaring what to pull and writing a pure mapping function), not a new pipeline. GitHub, Slack, and Notion are on the roadmap; none are wired up to sync yet.