Source connector

PostHog connector

PostHog integration for databases, warehouses and BI tools

Product analytics with session replay and flags. Datrise captures PostHog entities such as events, persons, sessions, feature flags, cohorts and insights, then lands normalized and typed models for warehouse reporting, attribution, and AI workflows.

The PostHog HTTP API (private REST endpoints) + Batch Exports authenticates with personal access token, incremental runs key on timestamp (via scheduled Batch Exports), and PostHog caps calls at Analytics endpoints (insights, persons, session recordings, etc.): 240 requests/minute and 1,200/hour; all other CRUD endpoints: 480 requests/minute and 4,800/hour.

Of the 6 objects, 4 sync as upserts keyed on the primary key and 2 as append-only streams, so each incremental run moves only what changed since the last watermark. Every object lands in its own table (for example `posthog_events`) with a schema derived from the PostHog API rather than a flattened CSV, in any of the 43 supported destinations.

Datrise is in early access: pick a destination below to open the PostHog pipeline page, and join the waitlist to get the PostHog connector with guided onboarding.

Incremental syncSchema-aware mapping43 destinations available

What PostHog data Datrise extracts

Each object lands in its own typed table. Sync mode is derived from the object: history-style objects append, everything else upserts.

Object	Landing table	Sync mode
events	posthog_events	Append-only, incremental by timestamp
persons	posthog_persons	Upsert by primary key, incremental on updated-at
sessions	posthog_sessions	Append-only, incremental by timestamp
feature flags	posthog_feature_flags	Upsert by primary key, incremental on updated-at
cohorts	posthog_cohorts	Upsert by primary key, incremental on updated-at
insights	posthog_insights	Upsert by primary key, incremental on updated-at

PostHog API: setup facts for the connector

Verified against the vendor documentation on 2026-09-02. Unknown values are left blank rather than guessed.

API	PostHog HTTP API (private REST endpoints) + Batch Exports
Authentication	personal access token — Private (non-capture) endpoints require a Personal API Key sent as an `Authorization: Bearer` token, scoped to a specific project/organization and permission set.
Pagination	offset — List endpoints return `count`/`next`/`previous`/`results`; `offset` and `limit` control paging, with a default page size around 100 (some endpoints use 500 or 1000).
Rate limit	Analytics endpoints (insights, persons, session recordings, etc.): 240 requests/minute and 1,200/hour; all other CRUD endpoints: 480 requests/minute and 4,800/hour
Incremental cursor	timestamp (via scheduled Batch Exports) — The ad-hoc Events API (`after`/`before` filters) is deprecated for production extraction — it caps `offset` pagination at 50,000 and the `before`/`after` window at under a year — so PostHog directs incremental/bulk extraction to scheduled Batch Exports instead.
Webhooks	Yes — CDP Webhook destination (event-triggered outbound HTTP)
Bulk export	Yes — Batch exports (S3, BigQuery, Snowflake, Postgres, Redshift) run on hourly/daily Temporal schedules
Deletes detectable	No

Official API reference

What bites when replicating PostHog

The Events API disables `offset` pagination past 50,000 and rejects `before`/`after` windows spanning a year or more, so it cannot be used to page through a large historical event backlog; use Batch Exports for bulk/historical pulls instead.
Without an explicit `after` parameter, the Events API silently defaults to only the last 24 hours, which can look like an empty dataset rather than an error if a connector expects an unbounded query.
Analytics-shaped endpoints (insights, persons, session recordings) share a much tighter rate-limit bucket (240/min, 1,200/hour) than general CRUD endpoints (480/min, 4,800/hour), so mixing both call types under one client can trip the tighter limit unexpectedly.
Events are immutable and there is no deletion feed for them; deleting a person via `DELETE /persons/{id}` can also cascade-delete that person's events with `delete_events=true`, but nothing in the API signals which events were removed after the fact.

Compare this against every other documented API