Skip to main content
A connector is not a product SKU. It’s a contract. Strip ingestion to first principles and a source system only needs to supply three things: records with a stable identity, a payload, and a source timestamp. Everything else (deduplication, normalization into events, actor identity resolution, provenance, extraction) is Seyn’s job, and it’s identical for every source. That has a direct consequence: the catalog is not the boundary of what Seyn can ingest. Prebuilt connectors are just connectors we maintain for you. If your data lives somewhere we haven’t built for yet, you don’t wait for us.

​
The contract

Three guarantees hold for every connector, prebuilt or custom:
  1. Read-only, always. No connector writes to a source system. See Security.
  2. Idempotent ingestion. Every record is deduplicated by content hash; re-running a sync never creates duplicates.
  3. Observable syncs. Every run produces a sync record with per-stage counters, visible on the connector’s detail page.
And the division of labour is fixed:
The connector suppliesSeyn guarantees
A stable record ID per itemContent-hash deduplication across every sync
The raw payload, verbatimVerbatim preservation as the bottom of the provenance chain
A source timestampEvent time = source time, not ingestion time
A mapping from payloads to events (who did what to which entity, when)Actor identity resolution, the event store, extraction, querying

​
Build your own

A custom connector is that contract, implemented by you, over the Ingestion API:
  • Register a source. POST /v1/sources returns a sourceId for the system you’re bringing in.
  • Push records in batches. POST /v1/ingest takes records shaped as { recordId, entityType, payload, sourceUpdatedAt }, up to 500 at a time. Full dumps work; incremental feeds (everything since a cursor) make re-syncs cheap, and content-hash dedup means re-sending an unchanged record is a no-op.
  • Seyn does the rest. Dedup, normalization into events, identity resolution, provenance linking, extraction, and querying treat your records exactly like records from a prebuilt connector. Same chain, same receipts.
That’s the whole surface. A CSV export, an internal tool’s API, a legacy database, a logistics system we’ve never heard of: if it can produce records, it can be a connector. Full request and response shapes are in the API Reference, and the SDK wraps them in typed methods. 
const source = await client.sources.create({ name: "Internal CRM", entityTypes: ["deal"] });

await client.ingest({
  sourceId: source.id,
  records: [
    {
      recordId: "deal-4471",
      entityType: "deal",
      sourceUpdatedAt: "2026-06-10T14:03:00Z",
      payload: { name: "Acme Corp renewal", stage: "negotiation", owner: "jane.smith@acme.com" },
    },
  ],
});
Early access. The Ingestion API and the contract behind it are stable and are the same path our own connectors use, but ingestion requires an API key with the ingest scope, granted per organisation during alpha. Request access and we’ll enable a write-scoped key and onboard your source together.

​
Prebuilt connectors

Prebuilt connectors add what generic ingestion can’t know: each source’s auth flow, delta semantics, edit and delete behaviour, and quirks.
ConnectorWhat it ingestsAuthSync model
SharePointDocument libraries, with folder-level allow-list policiesMicrosoft OAuthDelta sync, per-drive checkpoint
OutlookEmail, optionally attachmentsMicrosoft OAuthDelta sync, per-folder checkpoint
Outlook CalendarMeetings, invites, and attendeesMicrosoft OAuthDelta sync
Microsoft TeamsChannel messages and replies; optional meeting transcripts In testingMicrosoft OAuthDelta sync, per-channel checkpoint
Google DriveDocuments and shared drivesGoogle OAuthIncremental change feed
GmailEmail and threadsGoogle OAuthIncremental history sync
Google CalendarMeetings, invites, and attendeesGoogle OAuthIncremental sync tokens
SlackChannel messages and threadsSlack OAuthIncremental
Document InboxSelf-serve upload: loose files or ZIP archivesUpload, no credentialsOn upload. See Documents
More connectors land regularly. Anything not on this list can be ingested today as a custom connector, or tell us what you need and don’t wait.

​
How delta sync works

The Microsoft connectors use Graph delta queries: after the initial full sync, each run asks only “what changed since my last checkpoint?”
  • Atomic checkpoints, scoped small. The delta token is stored per drive, per channel, or per folder, and committed atomically with the records it covers. A crash mid-sync resumes from the last consistent point: never re-ingesting, never skipping.
  • Failure isolation. One channel or drive failing doesn’t abort the others; it’s recorded in the sync run and retried next time.
  • Expired tokens self-heal. When the source invalidates a delta token, the connector transparently restarts a full enumeration, and content-hash dedup makes that resync cheap and duplicate-free.
  • Edits and deletes propagate. Edited messages update their event in place; deletions soft-delete downstream events rather than breaking the provenance chain.

​
Honest limitations

  • Teams: standard channels only. Private and shared channels sit behind different permission models we haven’t validated yet.
  • Teams replies have no delta endpoint (a Microsoft Graph limitation), so replies are re-pulled when their parent changes.
  • Protected APIs. Some Teams data sits behind Microsoft’s Protected API approval. If a tenant lacks approval, the sync surfaces an explicit terminal status naming the admin action required. It doesn’t silently return partial data.
  • System messages are filtered. Joins, renames, and app-install notices are noise for process extraction and are dropped at ingestion.

​
Connector lifecycle

Planned: auto-sync. Per-connector schedules, opt-in post-sync knowledge rebuild, and staleness indicators are specified and coming. See Status.

​
Common mistakes

SymptomCauseFix
Synced data doesn’t show up in chatSync landed raw records, but no extraction run has processed them yetWalk the debugging order: sync → extraction → library → query
Teams sync ends in a terminal error mentioning consentThe tenant hasn’t granted admin consent or Protected API approvalThe error names the exact admin action; complete it in the Microsoft tenant and re-run
SharePoint sync ingests less than expectedFolder policies are an allow-list; paths outside it are skipped by designReview the connector’s folder policy configuration
Re-running a sync to “fix” data created no new recordsContent-hash dedup recognised everything. That’s correct behaviourIf source data changed, delta sync picks it up; if not, there’s nothing new to ingest

Events

The common schema your records are normalized into.

Documents

The deepest connector: parsing, extraction, and the upload inbox.