PostHog connector

Use this as an implementation starting point: adapt the worked example to the requested dataset and the source documentation. See Custom API for the shared SDK pattern and document-upload workflow.

What this connector is forCopy Anchor Link

Product event analytics, feature flags, experiments, and session information.

Use this guide to choose the resources and row meanings for a Vortexify source integration. Connection ownership belongs to a connector; each dataset gets its own sync, configuration, and extraction behavior.

Data and tables you can pullCopy Anchor Link

The following table families are a starting point for source selection. They describe possible datasets to implement using the vendor reference, not a guarantee that the example implements every table. Actual availability depends on the product edition, deployment, account permissions, and API/schema version.

Relationships and extraction considerationsCopy Anchor Link

These are proposed dataset names, not a universal schema guaranteed by the vendor. Preserve source object IDs and relationship references, and split nested child collections into separate tables when appropriate. Choose the concrete endpoint/report and row meaning from the vendor reference before implementing a sync.

Connecting to PostHogCopy Anchor Link

Authorize an account/application for the specific resources selected from the vendor reference. Confirm its scopes, region or tenant URL, API version, response shape, and pagination. An API subscription or enabled product can be required even when documentation is public.

For HTTP reads, configure the connector client with the concrete API origin and source-authorized headers or authentication object. Actual credentials belong in platform secret configuration, not in this document or committed source.

requirements.inCopy Anchor Link

Declare these packages in the resource's requirements.in. Use the published vortexify package for the SDK and the source-specific driver/client shown below. Choose compatible dependency versions for your runtime; the connector and sync reference explains where each file belongs.

vortexify==0.1.1
pandas>=2,<3
httpx

This HTTP starting point needs no native database driver. Add the source-specific SDK, signer, or XML parser if the selected interface requires it.

Worked example: bounded event query rowsCopy Anchor Link

This read function demonstrates the request and row mapping for one resource. Pass the owning connector's configured httpx.Client and dataset settings as config. Use the API origin as the client base URL; the function supplies the resource path. Token acquisition, renewal, signing, or session login belongs in the connector. This example reads one response; extend its continuation rule for a full dataset.

Source readCopy Anchor Link

import pandas as pd


def read_page(client, config):
    response = client.post(
        f"/api/projects/{config['project_id']}/query/",
        json={
            "query": {
                "kind": "HogQLQuery",
                "query": "SELECT event, timestamp FROM events LIMIT 100",
            }
        },
    )
    response.raise_for_status()
    payload = response.json()
    if isinstance(payload, dict):
        if (
            payload.get("errors")
            or payload.get("success") is False
            or payload.get("ok") is False
            or payload.get("result_ok") is False
        ):
            raise ValueError("Source returned an application error")
    rows = [dict(zip(payload["columns"], row)) for row in payload["results"]]
    if not isinstance(rows, list) or any(not isinstance(row, dict) for row in rows):
        raise ValueError("Expected the documented record array")
    return pd.json_normalize(rows)

What to adaptCopy Anchor Link

Use the regional PostHog instance API host and a personal API key with query permissions. This is a bounded query, not a complete event export. Add explicit time windows and a deliberate continuation design for larger datasets.

Use the custom API SDK starting point to connect the read operation to Connector and Sync. For a source with its own driver, retain that client in Connector.client() and replace the HTTP request with the driver read. An extract(*, avg_row_size_bytes=None) implementation yields bounded DataFrames. An independent preview() uses a fresh connector and a small read; it must not call extraction or advance real state.

Choose explicit output columns and stable IDs for the requested table. The examples use json_normalize where useful to illustrate row shaping; nested arrays still need deliberate child tables and a stable declared output schema. A first-page sample is useful for development, while a full sync must follow all relevant continuation/parent-resource paths. Design incremental watermarks, update/deletion behavior, and rate-limit handling for the actual source before enabling incremental mode.

The purpose is to give a coding agent a concrete pattern to adapt, including for similar sources. These snippets are examples rather than a claim of complete vendor coverage. Check the source operation reference and representative responses before running with a customer's account; live vendor execution has not been verified here.

Sources and further readingCopy Anchor Link

• Vendor connection and resource reference — The interface/access prerequisites underlying this connection path; follow the selected resource's documentation for fields, queries, and pagination.
• Vortexify connectors and syncs — Connector ownership, schemas, preview isolation, extraction, and checkpoint contracts.
• Vortexify CLI workflow — Registering resources, committing source, and providing credential configuration.