Source: https://qbash.com/docs/connectors/posthog Connect a PostHog personal API key to manage saved insights, dashboards and feature flags from qbash Tasks. ## Create a personal API key 1. Open [PostHog](https://app.posthog.com/signup) and sign in or create your account. Choose the region that holds your project. 2. Open your account settings, then **Personal API keys**. Create a key restricted to the projects your Tasks need. 3. Select `organization:read` and `project:read` for discovery. Add `insight:read`, `dashboard:read` and `feature_flag:read` for the resources you want to inspect. Add the matching `:write` scopes only when your Tasks need to create, update or delete those resources. 4. Copy the personal key, which begins with `phx_`. Project ingestion keys (`phc_`) and project secret keys (`phs_`) are not supported by this connector. See PostHog's [personal API key instructions](https://posthog.com/docs/api/personal-api-keys) for account-specific restrictions. ## Add the credential in qbash Open **Connectors → PostHog → Add Credential**. Enter a name, your personal API key and the host for your account: | Deployment | Host | | --- | --- | | US Cloud | `https://us.posthog.com` | | EU Cloud | `https://eu.posthog.com` | | Self-hosted | Your public HTTPS origin, without a path | Self-hosted addresses must use port 443 and resolve to public IP addresses. Redirects are refused. Saving checks the fields without making a PostHog API call. Your first Task call checks access. When editing, leave the key blank to retain it. Check the host carefully: changing it sends the saved key to the new host on the next call. ## Read saved insights Select the credential under your Task's **Tools → Integrations**, then use your project's numeric ID: ```python page = qbash.integrations.posthog.list_insights(project_id="123", limit=25) qbash.output(page) ``` List methods return `items` and `next_cursor`. Pass `next_cursor` back as `cursor` for the next page, using the same credential, host and resource. A cursor retains its original page size. Stop when it is `None`. Use `list_organizations`, then `list_projects(organization_id="...")` to discover projects. Organization and project responses return discovery metadata only, excluding embedded project tokens. Insight methods use numeric IDs, not short IDs from share links. See the [SDK Reference](https://qbash.com/docs/sdk-reference) for method parameters. ## Test with a small project Create a dashboard and saved insight in a dedicated PostHog test project to exercise list and get methods. Feature-flag checks need a flag in that project. Start with read scopes. Test writes only on disposable resources you own, and inspect each result before retrying a failed write. Before updating or deleting a feature flag, call `get_feature_flag` and pass its top-level `version` to `update_feature_flag` or `delete_feature_flag`. This is the resource revision, not `filters.version`; flags with `filters.version=2` require it. A `409` may indicate a stale version or an approval policy. Read the flag again and reconsider the change; the connector does not fetch a replacement version or retry the write automatically. Older flags can omit the version, but sending it protects against concurrent changes. Delete methods soft-delete resources with PATCH and verify the returned deletion flag; they do not hard-delete them. The connector makes one HTTP request per call and does not retry or page automatically. A `403` means the key lacks access or a required scope. A `401` means authentication failed. PostHog's [API limits](https://posthog.com/docs/api) apply. Responses larger than 5 MB are refused. ## Scope This connector manages saved resource definitions. It does not run `/query`, export events or evaluate flags for an end user. PostHog's [Query API guidance](https://posthog.com/docs/api/queries) directs third-party connectors to batch or file exports. Those export workflows are not implemented here. The native methods cover part of PostHog's official MCP resource-management capabilities, not full MCP parity.