Ingest tl;dv meeting recordings and speaker-segmented transcripts into CortexDB.

tl;dv Connector

Captures tl;dv meetings and their speaker-segmented transcripts as CortexDB experiences — one episode per meeting, stamped with the meeting's real time so your meeting timeline is queryable alongside everything else.

Info

Two ways to run this connector:

Run it yourself (Free + paid) — pip install cortexdb-connectors then cortexdb-sync sync tldv. The connector reads your token from ~/.cortexdb/state.json (written by cortexdb init) or from env vars.
Managed sync (Starter and up) — CortexDB runs the same connector as a worker on its infrastructure. Configure it once from your dashboard; CortexDB handles scheduling, retries, backfill, and idempotency.

1. Prepare credentials in tl;dv

tl;dv → Settings → API. Copy the API key. The connector sends it as the x-api-key header.

2. Configure in your CortexDB dashboard

Sign in at cortexdb.ai/login.
Settings → Connectors → Add Connector → tl;dv.
Paste the API key.
Set the scope template. Default: org:<your-org>/source:tldv.
Click Start sync.

What gets written

One episode per meeting, episode_type = meeting, whose content is the meeting name followed by the transcript rendered as speaker-attributed turns.

Field	Value
`occurred_at`	The meeting's real `happenedAt` time, not ingest time
`actor`	The organizer's display name and email
`thread_id`	`tldv:meeting:<meeting_id>`
`entities`	One `meeting` entity, so you can scope by `{entity.meeting}`
`metadata`	`meeting_id`, `name`, and the tl;dv `url`

Visibility

Derived per meeting from tl;dv's own privacy signals — explicit private/visibility flags and invitee count — rather than a fixed level:

Signal	Visibility
Marked private, or a 1:1	`private`, with invitees as the allow-list
Limited invitee set	`restricted`, with invitees as the allow-list
Otherwise	`organization`

For hard per-meeting isolation, use a scope template containing {entity.meeting} — each meeting then lands in its own scope subtree.

Idempotency and history

tldv:<meeting_id>:<content-digest>

The key is content-versioned, which matters more here than for most sources: a meeting is often listed before its transcript is ready. When the transcript later arrives — or the meeting is re-transcribed or renamed — the content changes, so a new key is minted and the corrected version lands as retained history. A key based on the meeting id alone would reject it and error on every subsequent sync.

Real-time delivery (webhook)

tl;dv does not sign its payloads, so the receiver authenticates on a static header.

export TLDV_WEBHOOK_SECRET=<a long random string>
cortexdb-sync serve --port 8081

Point tl;dv's MeetingReady / TranscriptReady webhooks at POST https://<your-host>/webhooks/tldv/events with Authorization: Bearer <the same secret>.

The webhook path builds its episode through the same builder as polling, so a meeting seen by both paths dedupes to one stored copy instead of double-storing.

Run it yourself

pip install cortexdb-connectors

# Step 1: get a CortexDB token + actor (one-time, free tier)
pip install cortexdb-cli
cortexdb init

# Step 2: supply the connector's third-party credentials
export TLDV_API_KEY=...        # required

# Step 3: one-shot sync, or `watch` for a poll loop
cortexdb-sync sync tldv
cortexdb-sync watch tldv --interval 300

cortexdb-sync reads your CortexDB token + actor from ~/.cortexdb/state.json automatically. Cursor state is persisted in ~/.cortexdb/sync_state.json, so re-running picks up where the last cycle left off.

Behaviour worth knowing

Late transcripts are handled. The connector re-lists a 24-hour window behind its stored cursor, so a meeting whose transcript becomes ready after a newer meeting already advanced the cursor is still picked up.
Rate limits and outages are retried with backoff on 429 and 5xx, honouring Retry-After.
A failed transcript fetch is logged loudly rather than silently ingesting a meeting with an empty body.
Deletions are not propagated. A meeting deleted in tl;dv remains in CortexDB as retained history.