Curiosity

Connect & Ingest

Connect built-in integrations or write custom connectors that ingest typed nodes and edges into the graph — and keep them in sync.

Browse integrationsBrowse connector recipes

This section is for developers and admins getting data into Curiosity Studio — connecting built-in integrations and writing custom connectors that keep the graph fresh.

For the schema and graph concepts behind ingestion, see Learn Curiosity Studio. To deploy and operate the platform, see Deploy and manage. To extend the workspace with endpoints, AI tools, and custom front-ends, see Build enterprise AI apps.

Curiosity Studio ships with built-in integrations for the systems most teams already rely on — cloud storage, email, calendars, chat, knowledge bases, issue trackers, CRMs, and the open web. Each integration is a packaged data connector: it authenticates against the source, ingests typed nodes and edges into the workspace graph, and runs on a schedule so the graph stays in sync.

When the built-in list doesn't fit your data, you write a custom connector with the Curiosity.Library SDK. The Recipes section walks through reusable, runnable examples (CSV, JSON, REST, SQL, Kafka, S3, PDFs, …) that you can fork as a starting point.

How data flows from a source to the graph

Every integration — whether it's a built-in SaaS connector or a custom recipe you wrote — follows the same pipeline. Source records become typed nodes; relationships become edges; permissions become access-group memberships; everything is keyed for idempotent merges.

flowchart LR Src[(Source system)] -->|read / OAuth| Conn[Connector] Conn -->|Schema registration| Schema[Node & edge types] Conn -->|TryAdd / Link| Pending[Pending writes] Pending -->|CommitPendingAsync| Graph[(Graph)] Conn -->|ACLs| AG[Access groups] AG --> Graph Graph -->|background| Parsers[Parsers / OCR / NLP] Graph -->|background| Indexers[Search indexers] Indexers --> Search[(Search index)] Conn -. cursor / watermark .-> State[(Connector state)]
One graph, many sources

Every connector emits nodes with a stable [Key]. When two connectors emit a node with the same key, the workspace merges rather than duplicates. That is what lets your Slack-of-record meet your Jira-of-record meet your Confluence-of-record in one searchable graph.

What gets ingested

Each integration documents three things up front so you can decide quickly whether it fits:

Data synchronized

The exact node types created by the connector — files, messages, pages, tickets, contacts, events, custom records — and the edges between them.

Access control mapping

Whether the source system's ACLs (per-file sharing, channel membership, project roles) are carried into the workspace graph as access groups.

Authentication

What the user needs to provide — OAuth login, an API token, a service account, or anonymous access — and what scopes are requested.

Built-in integrations

Browse by category. Each card links to a page with the data model, ACL mapping, authentication flow, and any source-specific behavior worth knowing.

Cloud storage

AWS S3

Buckets, prefixes, and objects ingested as files with full content extraction.

Azure Blob Storage

Azure containers and blobs as files with folder hierarchy preserved.

Box

Box files and folders with per-user access groups and event-stream delta sync.

Dropbox (Business)

Team and shared-folder content with namespaced delta cursors.

Dropbox (Personal)

Personal Dropbox accounts with per-user cursor-based delta sync.

FTP / SFTP

Recursive file ingestion from any FTP-compatible server.

Google Drive

My Drive and Shared Drives with Google Drive change-token delta sync.

Microsoft OneDrive

OneDrive (personal + business) files, including OneNote notebooks.

Microsoft SharePoint

SharePoint sites, libraries, pages, and document drives.

pCloud

pCloud files and folders via the diff-ID incremental API.

Email

Gmail

Threads, messages, attachments, and contacts with Gmail history-ID delta sync.

Microsoft Outlook

Outlook mail, attachments, contacts, and folder hierarchy via Microsoft Graph.

IMAP (generic)

Any IMAP mailbox — folders, messages, attachments — using username + password.

POP3

Flat inbox ingestion for legacy POP3 servers.

Yahoo Mail

Yahoo Mail over IMAP with OAuth-refreshed tokens.

Calendar

Google Calendar

Calendars and events with per-calendar delta tokens.

Outlook Calendar

Microsoft Graph calendars and events, including shared calendars.

Chat & messaging

Slack

Channels, threads, messages, files, and members with per-channel access groups.

Microsoft Teams

Teams, channels, channel messages, attachments via Microsoft Graph delta links.

Knowledge bases

Confluence

Spaces, pages, attachments — single-user and multi-user variants.

Evernote

Notebooks, notes, tags, resources — including linked / shared notebooks.

Notion

Workspaces, pages, databases, and blocks rendered to HTML.

Issue tracking & code

GitHub

Repos, issues, pull requests, comments, and users via the GitHub GraphQL / REST APIs.

Jira

Projects, issues, comments — Atlassian Cloud OAuth-authenticated.

CRM & business apps

Airtable

Custom tables with dynamic schema inferred from the first batch.

HubSpot

Contacts, companies, deals, meetings, notes, emails, tasks, and files.

Salesforce

Leads, contacts, accounts, opportunities, and custom objects.

Zendesk

Organizations, users, tickets, comments, and attachments.

Web & feeds

RSS / Atom

Feed items as web pages, optionally crawling linked articles.

Web Crawler

Generic crawler with robots.txt, content-type filters, and video transcription.

Choosing an integration vs. building a recipe

Use the built-in integration when it exists

It already handles OAuth refresh, delta sync, ACL mapping, and retries. Drop down to a recipe only when you need custom mapping, custom keys, or a source the built-in list doesn't cover.

Use a built-in integration

Available out of the box — configured by an admin from Manage → Integrations. Zero code. OAuth and tokens handled by the workspace.

Write a connector from a recipe

Fork one of the 13 recipe templates. Reuse the source-format reader; rewrite only the schema and ingest method. Run as a console app on cron or CI.

Need help?