feat(warehouse): sync Gong call participants and CRM associations

[simfish85]

Problem

PostHog's alpha Gong connector syncs four tables — calls, users, scorecards, workspaces — none of which carry call participants or CRM associations. That's because the calls table is fed by the basic GET /v2/calls list endpoint, which returns only flat call metadata. Gong exposes participant identities (parties) and CRM object links (context) exclusively through the separate POST /v2/calls/extensive endpoint, which the connector didn't call — so even with CRM association configured perfectly in Gong, there was no field to carry it into the warehouse.

Why: A user wanted their Gong calls joined to CRM/account data (and participant emails) inside PostHog, and found the synced calls rows had no association fields at all. This makes that data available.

Changes

• New calls_extensive data-warehouse table backed by POST /v2/calls/extensive, returning each call's parties (participant name/email/affiliation) and CRM context (linked Salesforce/HubSpot objects and fields).
• Reuses the existing date-windowed, cursor-paginated, incremental-on-started sync path. Added POST support to the fetcher (filter + content selector + cursor in the JSON body) and flattening of the extensive response's metaData wrapper so id/started stay top-level for merge and partitioning while parties/context become nested columns.
• Kept as a separate table so enabling it never changes the existing calls schema.
• Documents the additional api:calls:read:extensive scope in the connection caption, and adds canonical column descriptions for the new table.

How did you test this code?

Added unit tests in test_gong.py covering the new path: that calls_extensive issues a POST to /v2/calls/extensive with the correct contentSelector (Extended context + parties), flattens metaData up while preserving parties/context, and passes the pagination cursor in the body rather than the query string. Updated the endpoint-set assertion to include the new table.

I (the agent) was not able to run the repo's pytest suite in this environment (dev dependencies aren't installed). I verified all edited modules byte-compile and exercised the new body-building and flattening logic in a standalone harness. The tests follow the existing _FakeSession patterns in the file and should be run in CI.

🤖 Agent context

Autonomy: Human-driven (agent-assisted)

Authored by the PostHog Slack app from a support thread. The root cause was diagnosed by inspecting the connector source (basic /v2/calls vs /v2/calls/extensive) and confirming the synced tables carry no association data. Chose to add a dedicated calls_extensive table rather than switch calls to the extensive endpoint, to avoid a breaking schema change to an existing table. No repo skills were invoked.

---

Created with PostHog from a Slack thread

[github-actions]

Hey @simfish85! 👋

It looks like your git author email on this PR isn't your @posthog.com address (simfish85@googlemail.com). Since you're on the PostHog team, it's worth pointing your local git author email at your @posthog.com address. Why it matters:

• Consistent work identity in git history — internal tooling that attributes commits to team members keys off your @posthog.com address.
• Keeps team contributions easy to tell apart from external community ones when scanning history.

You can fix it for this repo with:

git config user.email "you@posthog.com"

Or set it globally with git config --global user.email "you@posthog.com". No need to redo this PR — just a nudge for next time. 🙂

[veria-ai]

PR overview

All previously flagged issues have been addressed. No open security concerns remain on this pull request.

Security review

No open security issues remain on this pull request.

Fixed/addressed: 1 · PR risk: 0/10

[trunk-io]

     

View Full Report ↗︎ ⋅ Docs

[deployment-status-posthog]

Deploy status

Environment	Status	Deployed At	Workflow
dev	✅ Deployed	2026-07-16 09:03 UTC	Run
prod-us	✅ Deployed	2026-07-16 09:16 UTC	Run
prod-eu	✅ Deployed	2026-07-16 09:19 UTC	Run

[gvago]

hey @Gilbert09,
I only came across PostHog last week and already using it (great product), and would love to contribute, but i also don't like to push myself on to the OSS.
I noticed you ran veria-ai and now some greptile... and wondered y not qodo (not the lame old FOOS, the full enterprise edition FOC)

You have a ton of PRs waiting.

writing to you here since i noticed that if you run pnpm --filter=@posthog/frontend typegen:write (or the repo’s kea-typegen command) in CI/local and observe whether it errors or writes inline type output into unexpected locations due to inlinePaths entries pointing at non-existent ./frontend/src/.kea-inline-* paths relative to rootPath.