Linking Helicone as a source
Let AI connect your sources for you
Skip the manual setup — run this in your project and the wizard auto-detects your databases and APIs and connects them to PostHog.

Contents
The Helicone connector syncs your logged LLM requests, sessions, per-user usage aggregates, and prompts from Helicone into PostHog. This lets you join LLM cost, token usage, and latency data with your product analytics.
Prerequisites
You need a Helicone account with an API key. Any Helicone plan works, but the amount of request history you can sync depends on your plan's data retention.
Adding a data source
- In PostHog, go to the Sources tab of the data pipeline section.
- Click + New source and click Link next to this source.
- Enter your credentials (see Configuration below) and click Next.
- Select the tables you want to sync, choose a sync method and frequency, then click Import.
Once the syncs are complete, you can start querying this data in PostHog.
To connect, you need:
- API key – generate one in your Helicone dashboard under Settings → API Keys.
- Region – pick US or EU to match where your Helicone organization is hosted.
Sync modes
Each table can be synced in one of several modes, depending on what the source supports:
- Webhook (when available) – the source pushes changes to PostHog in real time. Fastest freshness, lowest ongoing cost, and the only mode that reliably captures updates and deletes.
- Incremental – only new or updated rows are synced on each run, using a cursor field (such as an
updated_attimestamp). Cheaper than a full refresh, but deletes aren't captured. - Append only – new rows are appended using a cursor field; existing rows are never updated. Ideal for immutable, append-only tables like event logs.
- Full refresh – the whole table is reloaded on every sync. Use it when a table has no reliable cursor or when you need deletions reflected.
See sync methods for a full explanation of how each mode works and how to choose between them.
The requests table is an append-only log, so incremental sync on request_created_at is recommended. Only the last 365 days are pulled on the initial incremental sync; subsequent runs fetch only newer requests. The sessions, users, and prompts tables contain aggregates and metadata that change in place, so they sync as full refreshes.
Configuration
| Option | Type | Required |
|---|---|---|
API key | password | Yes |
Region | select | Yes |
Supported tables
| Table | Description | Sync method | Incremental field | Primary key |
|---|---|---|---|---|
requests | Only syncs the last 365 days on initial incremental sync | Incremental, Full refresh | request_created_at | — |
sessions | Aggregated metrics for each Helicone session (requests grouped via the Helicone-Session-Id header): totals for cost, requests, and tokens, plus the users involved. | Full refresh | — | — |
users | Per-user usage aggregates across all logged requests: request count, token usage, and cost, keyed by the Helicone-User-Id header value. | Full refresh | — | — |
prompts | Prompts managed in Helicone's prompt registry, with their names and tags. | Full refresh | — | — |
properties | Catalog of the custom property keys (set via Helicone-Property-* headers) seen on the organization's requests, excluding keys hidden in Helicone. | Full refresh | — |





