Everything an AI agent can do with the PostHog API.

A reference guide for building AI agents: every method, how to authenticate, and the permissions each one needs.

Endpoints27
AuthenticationPersonal API key
Last updated23 June 2026
Orientation

How the PostHog API works.

The PostHog API is how an app or AI agent works with a PostHog project: sending events in, running HogQL queries to read them back, reading and updating the people behind the analytics, and managing feature flags, insights, and experiments. Access splits in two: a project key sends events in and carries no permissions, while a personal API key reads and manages data and carries fine-grained scopes, each set to read or write per resource and limited to chosen organizations and projects. There is no dated version to pin, since one continuously updated API is announced through a changelog.

27Endpoints
10Capability groups
15Read
12Write
17Permissions
Authentication
Two kinds of key serve two purposes. A personal API key, prefixed phx_, is sent as an Authorization Bearer token and authenticates the private read and management endpoints. A project API key is sent in the request body and authenticates the public capture and flag-evaluation endpoints, which return no sensitive data. The private endpoints answer at us.posthog.com or eu.posthog.com, and the public ones at us.i.posthog.com or eu.i.posthog.com, depending on the data region.
Permissions
A personal API key carries a chosen set of fine-grained scopes, each named resource:read or resource:write, such as insight:read, feature_flag:write, person:read, query:read, cohort:write, dashboard:read, annotation:write, experiment:read, and action:write. A key can be limited to specific organizations and specific projects, or left unscoped for all of them. The project API key used for capture carries no scopes at all. PostHog recommends granting a key only the scopes the integration actually needs.
Versioning
The API does not carry a dated version string an integration pins. There is a single, continuously updated API, addressed by path. Resources sit under a project or environment id, such as /api/projects/:project_id/feature_flags/ and /api/environments/:environment_id/insights/. Breaking changes are announced through the changelog rather than a version header.
Data model
The API is resource-oriented JSON over HTTPS. Ingestion is separate from management: events arrive through the public capture endpoints and are read back through HogQL queries and saved insights. Most management resources, like feature flags, cohorts, annotations, experiments, and actions, sit under /api/projects/:project_id/, while persons, insights, and dashboards now sit under /api/environments/:environment_id/. A hosted MCP server exposes the same capabilities to AI agents.
Connect & authenticate

Connection & authentication methods.

How an app or AI agent connects to PostHog determines what it can reach. There is a route for sending events, a route for reading and managing data, and a hosted server that exposes PostHog tools to agents, and each is governed by the key behind it and the scopes that key carries.

Ways to connect

REST API

The private REST API answers at us.posthog.com on US Cloud and eu.posthog.com on EU Cloud, and handles all reading and management. It authenticates with a personal API key and is scoped by that key's permissions.

Best forReading and managing a PostHog project from an app or AI agent.
Governed byThe personal API key and the scopes it carries.
Docs ↗

Event capture API

The public capture API answers at us.i.posthog.com on US Cloud and eu.i.posthog.com on EU Cloud, and takes events into PostHog. It authenticates with the project token in the request body, carries no scopes, and is not rate limited.

Best forSending events and identifying people from an app or AI agent.
Governed byThe project token, which has no scopes.
Docs ↗

MCP server (Model Context Protocol)

PostHog runs a hosted MCP server at mcp.posthog.com/mcp that lets an agent work with PostHog through the Model Context Protocol, including reading insights, running HogQL queries, managing feature flags, and inspecting errors. The login routes to the right region, US or EU, and the source lives in the PostHog monorepo at github.com/PostHog/posthog under services/mcp.

Best forConnecting an AI agent to PostHog through MCP.
Governed byThe personal API key and the scopes it carries.
Docs ↗
Authentication

Personal API key

A personal API key, prefixed phx_, is sent as 'Authorization: Bearer ' and authenticates the private read and management endpoints. Each key carries a chosen set of scopes, each set to read or write per resource, and can be limited to specific organizations and projects or left unscoped.

TokenPersonal API key (phx_)
Best forScripts, automations, and agents tied to one account
Docs ↗

Project API key

A project API key authenticates the public capture and flag-evaluation endpoints by being sent in the request body. It is tied to one project, carries no scopes, and is safe to expose in client code because it cannot read data back.

TokenProject API key
Best forSending events and evaluating flags from clients
Docs ↗

OAuth

OAuth lets an app that other PostHog users install request scoped access to their account, so they grant permission without sharing a personal API key.

TokenOAuth access token
Best forApps installed by other PostHog users
Docs ↗
Capability map

What an AI agent can do in PostHog.

The PostHog API is split into areas an agent can act on, like events, queries, persons, insights, and feature flags. Each area has its own methods and its own scope, and reading persons returns the people and properties behind the analytics.

Event capture

2 endpoints

Send a single event or a batch of events into PostHog for ingestion.

Writes here add real events to a project's data.
View endpoints

Query (HogQL)

1 endpoint

Run a HogQL query, PostHog's SQL dialect, to read events, persons, and aggregates.

A query can read across a project's events and people.
View endpoints

Persons

4 endpoints

List, read, update, and delete the people PostHog has tracked and their properties.

This area returns and changes real person records.
View endpoints

Insights

3 endpoints

List, read, and create saved insights, the charts and tables built from events.

Writes here change real saved insights.
View endpoints

Feature flags

5 endpoints

List, read, create, and update feature flags, and evaluate flags for a person.

Writes here change which users see a feature in production.
View endpoints

Cohorts

3 endpoints

List, read, and create cohorts, the saved groups of people that match a rule.

Writes here change real saved cohorts.
View endpoints

Dashboards

3 endpoints

List, read, and create dashboards, the collections of insights shown together.

Writes here change real saved dashboards.
View endpoints

Annotations

2 endpoints

List and create annotations, the dated notes that mark events on a chart.

Writes here add real annotations to a project.
View endpoints

Experiments

2 endpoints

List and create experiments, the A/B tests built on top of feature flags.

Writes here change real running experiments.
View endpoints

Actions

2 endpoints

List and create actions, the saved combinations of events used across PostHog.

Writes here change real saved actions.
View endpoints
Endpoint reference

Every PostHog API method.

Filter by method, access, or permission, or search any path. Select a row for version detail, rate limits, the related webhook event, and the source.

MethodEndpointWhat it doesAccessPermissionVersion

Event capture

Send a single event or a batch of events into PostHog for ingestion.2

A public POST-only endpoint that authenticates with the project API key sent in the request body, not a personal API key. It carries no scopes and is not rate limited.

Acts onevent
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitNot rate limited

A public POST-only endpoint that authenticates with the project API key in the request body. It carries no scopes and is not rate limited.

Acts onevent
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitNot rate limited

Query (HogQL)

Run a HogQL query, PostHog's SQL dialect, to read events, persons, and aggregates.1

The main endpoint for reading data from PostHog. A HogQL query can reach events, persons, and aggregates across the project, so this single scope grants broad read access.

Acts onquery
Permission (capability)query:read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limit2,400/hour

Persons

List, read, update, and delete the people PostHog has tracked and their properties.4

Returns person records and their properties, which can include names, emails, and other identifying fields that were captured.

Acts onperson
Permission (capability)person:read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limit240/minute and 1,200/hour

Returns one person's full property set.

Acts onperson
Permission (capability)person:read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limit240/minute and 1,200/hour

PostHog recommends setting person properties through capture and the SDKs rather than this endpoint, which is meant mainly for reading and deleting.

Acts onperson
Permission (capability)person:write
VersionAvailable since the API’s base version
Webhook eventNone
Rate limit240/minute and 1,200/hour

Deletes person records and can also delete the events tied to them, which removes data permanently.

Acts onperson
Permission (capability)person:write
VersionAvailable since the API’s base version
Webhook eventNone
Rate limit240/minute and 1,200/hour

Insights

List, read, and create saved insights, the charts and tables built from events.3

Reading an insight returns its definition and computed results.

Acts oninsight
Permission (capability)insight:read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limit240/minute and 1,200/hour

Computing the insight result can be the slow part of this call.

Acts oninsight
Permission (capability)insight:read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limit240/minute and 1,200/hour

Creates a new saved chart or table that others on the team will see.

Acts oninsight
Permission (capability)insight:write
VersionAvailable since the API’s base version
Webhook eventNone
Rate limit480/minute and 4,800/hour

Feature flags

List, read, create, and update feature flags, and evaluate flags for a person.5

Returns each flag's key, rollout, and targeting rules.

Acts onfeature flag
Permission (capability)feature_flag:read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limit240/minute and 1,200/hour

Returns one flag's full definition.

Acts onfeature flag
Permission (capability)feature_flag:read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limit240/minute and 1,200/hour

A new flag can immediately change which users see a feature, depending on its rollout.

Acts onfeature flag
Permission (capability)feature_flag:write
VersionAvailable since the API’s base version
Webhook eventNone
Rate limit480/minute and 4,800/hour

Changing a rollout percentage here takes effect in production for matching users.

Acts onfeature flag
Permission (capability)feature_flag:write
VersionAvailable since the API’s base version
Webhook eventNone
Rate limit480/minute and 4,800/hour

A public POST-only endpoint that uses the project token, not a personal API key. It returns the flag values for a given distinct_id and is the endpoint SDKs call to decide what a user sees.

Acts onfeature flag
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitNot rate limited

Cohorts

List, read, and create cohorts, the saved groups of people that match a rule.3

Returns each cohort's definition and the rule that selects its people.

Acts oncohort
Permission (capability)cohort:read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limit240/minute and 1,200/hour

Returns one cohort's full definition.

Acts oncohort
Permission (capability)cohort:read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limit240/minute and 1,200/hour

Creates a saved group of people that other features, such as feature flags, can target.

Acts oncohort
Permission (capability)cohort:write
VersionAvailable since the API’s base version
Webhook eventNone
Rate limit480/minute and 4,800/hour

Dashboards

List, read, and create dashboards, the collections of insights shown together.3

Returns each dashboard and the insights it holds.

Acts ondashboard
Permission (capability)dashboard:read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limit240/minute and 1,200/hour

Returns one dashboard and its tiles.

Acts ondashboard
Permission (capability)dashboard:read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limit240/minute and 1,200/hour

Creates a new dashboard that the team will see.

Acts ondashboard
Permission (capability)dashboard:write
VersionAvailable since the API’s base version
Webhook eventNone
Rate limit480/minute and 4,800/hour

Annotations

List and create annotations, the dated notes that mark events on a chart.2

Returns the dated notes that mark events on charts.

Acts onannotation
Permission (capability)annotation:read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limit240/minute and 1,200/hour

Adds a dated note that appears on charts across the project.

Acts onannotation
Permission (capability)annotation:write
VersionAvailable since the API’s base version
Webhook eventNone
Rate limit480/minute and 4,800/hour

Experiments

List and create experiments, the A/B tests built on top of feature flags.2

Returns each A/B test and the feature flag behind it.

Acts onexperiment
Permission (capability)experiment:read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limit240/minute and 1,200/hour

Creating an experiment also creates the feature flag that splits its variants.

Acts onexperiment
Permission (capability)experiment:write
VersionAvailable since the API’s base version
Webhook eventNone
Rate limit480/minute and 4,800/hour

Actions

List and create actions, the saved combinations of events used across PostHog.2

Returns each saved combination of events that PostHog tracks as one action.

Acts onaction
Permission (capability)action:read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limit240/minute and 1,200/hour

Creates a saved action that insights and other features can reference.

Acts onaction
Permission (capability)action:write
VersionAvailable since the API’s base version
Webhook eventNone
Rate limit480/minute and 4,800/hour
No endpoints match those filters.
Webhooks

Webhook events.

PostHog can notify an app or AI agent when something happens, instead of the app repeatedly asking. A realtime destination or an action posts the matching event to a receiver URL that has been set up for it.

EventWhat it signalsTriggered by
No events match that search.
Rate limits & pagination

Rate limits, pagination & request size.

PostHog limits how fast an app or AI agent can call the private read and management endpoints, through per-minute and per-hour ceilings that vary by endpoint type, while the public event-capture endpoints are not rate limited.

Request rate

PostHog rate limits its private read and management endpoints, and the limit applies across the whole organization rather than per key. The analytics endpoints, such as listing persons, insights, and recordings, allow 240 requests per minute and 1,200 per hour. The query endpoint allows 2,400 per hour. Create, update, and delete endpoints allow 480 per minute and 4,800 per hour. The events and values endpoint is tighter at 60 per minute and 300 per hour, and feature flag local evaluation allows 600 per minute. The public event-capture and flag-evaluation endpoints are not rate limited, since they take ingestion and client traffic at volume. Going over a private limit returns a 429.

Pagination

List endpoints return a page of results with a 'results' array alongside 'next' and 'previous' links. Following the 'next' link until it is null walks the whole set, rather than building the URL by hand. Some endpoints use a cursor in that link rather than a numbered page.

Request size

Requests and responses are JSON. The practical cost on the read side is computing the result, since a HogQL query or a heavy insight can scan a large volume of events, rather than a fixed payload size limit. The capture endpoints accept either a single event or a batch in one request.

Errors

Status codes & error handling.

The status codes an agent should handle, and what to do about each.

StatusCodeMeaningWhat to do
401UnauthorizedAuthentication is missing or the personal API key is invalid or expired.Send a valid personal API key in the Authorization header as a Bearer token.
403Permission deniedThe key is valid but its scopes do not cover the endpoint, or it is not scoped to the requested project or organization.Grant the missing scope, such as insight:read or feature_flag:write, or widen the key's project and organization access.
404Not foundThe resource does not exist, or the key cannot see it under its current project scope.Confirm the path, the project or environment id, and that the key reaches that project.
429ThrottledA rate limit was exceeded on a private endpoint. The limit applies across the whole organization, not per key.Slow down and retry after the window resets, using the Retry-After header when present.
Versioning & freshness

Version history.

PostHog does not put a dated version number in its API. There is a single, continuously updated API, and breaking changes are announced through the changelog rather than a version string an integration pins.

Version history

What changed, and when

Latest versionCurrent
CurrentCurrent version
Single continuously updated API

PostHog does not put a dated version number in its API. There is one continuously updated API, addressed by path under a project or environment id, and breaking changes are announced through the changelog rather than a version header. The dated entries below are notable changes to the API surface, newest first.

What changed
  • Persons, insights, and dashboards moved under an environment id, /api/environments/:environment_id/, while most other resources stayed under a project id
  • Personal API keys gained fine-grained, per-resource scopes, replacing all-or-nothing access
  • A hosted MCP server launched at mcp.posthog.com/mcp, exposing PostHog tools to AI agents
2026-06-06Feature update
Saved insights and queries as API endpoints

PostHog made it possible to turn any saved insight or SQL query into a fast, versioned, authenticated API endpoint, with materialized queries and a configurable cache lifetime. These endpoints reached general availability on this date, and MCP tools for workflows were introduced alongside.

What changed
  • Saved insights and SQL queries can be exposed as authenticated API endpoints
  • Endpoints reached general availability
  • MCP tools for workflows introduced

An integration tracks changes through the changelog, since there is no dated version to pin.

PostHog changelog ↗
Questions

PostHog API, answered.

Personal API key or project API key, which do I use?+
It depends on the direction. A project API key is for sending data in, through the public capture and flag-evaluation endpoints, and it carries no scopes and returns no sensitive data, so it is safe in client code. A personal API key, prefixed phx_, is for reading data out and managing a project, through the private endpoints, and it is sent as an Authorization Bearer token. Reading insights, persons, or feature flag definitions needs a personal API key with the right scope.
How do scopes work on a personal API key?+
Each personal API key carries a chosen set of scopes, named resource:read or resource:write, such as insight:read or feature_flag:write. A call fails with a 403 if the key lacks the scope the endpoint needs. A key can also be limited to specific organizations and projects, or left unscoped to reach all of them. PostHog recommends selecting only the scopes the integration really needs, and a key can hold up to that minimal set rather than full access.
What are the rate limits?+
The private read and management endpoints are rate limited across the whole organization, not per key. Analytics endpoints allow 240 requests per minute and 1,200 per hour, the query endpoint allows 2,400 per hour, and create, update, and delete endpoints allow 480 per minute and 4,800 per hour. The events and values endpoint is tighter at 60 per minute. The public capture and flag-evaluation endpoints are not rate limited, since they handle ingestion and client traffic at volume. Going over a private limit returns a 429.
How does the query endpoint and HogQL work?+
The query endpoint is the main way to read data out of PostHog. It accepts a HogQL query, PostHog's SQL dialect, which can read events, persons, and aggregates across a project, so a single query:read scope grants broad read access. It has its own limit of 2,400 requests per hour. For saved charts and tables, the insights endpoints return the definition and the computed result instead.
Does PostHog have an MCP server for AI agents?+
Yes. PostHog runs a hosted MCP server at mcp.posthog.com/mcp that lets an AI agent work with PostHog through the Model Context Protocol, including reading insights, running HogQL queries, managing feature flags, and inspecting errors. Logging in routes the agent to the correct data region, US or EU. The source lives in the PostHog monorepo under services/mcp.
How do I receive events instead of polling?+
PostHog can push activity out through its realtime destinations and actions, which post a matching event to a receiver URL when it fires. This is set up in the platform rather than on the read API, and it suits reacting to an event without polling the query endpoint. For reading historical data, a HogQL query through the query endpoint is the route.
Related

More analytics API guides for agents

What is Bollard AI?

Control what every AI agent can do in PostHog.

Bollard AI sits between a team's AI agents and PostHog. Grant each agent exactly the access it needs, read or write, resource by resource, and every call is checked and logged.

  • Set read, write, or full access per agent, never a shared PostHog key.
  • Denied by default, so an agent reaches only what has been explicitly allowed.
  • Every call recorded in plain English: who, what, where, and the decision.
PostHog
Analytics Agent
Read insights ResourceOffReadFull use
Run HogQL queries ActionOffReadFull use
Edit feature flags ResourceOffReadFull use
Read persons ResourceOffReadFull use
Per-agent access, set in Bollard AI, not in PostHog