Endpoints
Contents
Endpoints turn a saved insight or SQL query into a named, callable API route. You write the query once in PostHog, give it a name, and your app fetches the results over HTTP – no query strings to assemble in client code, and no query logic scattered across your services.
Because the query lives in PostHog, you get versioning, execution logs, and optional materialization for free. That makes endpoints a good fit for customer-facing analytics and internal tools, where the same query runs constantly and needs to stay fast and predictable.
Endpoints is in early beta and free to use while it is. We're always looking for feedback, so reach out to us directly in app.
Where you can use it
You build and monitor endpoints in the PostHog web app, then call them from your own code. MCP and PostHog Desktop are for creating and debugging endpoints from an AI tool.
PostHog Web
Create endpoints, test them in the playground, and watch usage and execution logs.
Build an endpoint →API
Call your endpoint over HTTP from any language, or generate a typed client from its OpenAPI spec.
Call an endpoint →PostHog MCP
Create, run, version, and debug endpoints from Claude Code, Cursor, or any MCP client.
Manage endpoints →PostHog Desktop Beta
Build endpoints and wire them into your app, with your repo and PostHog side by side.
Build with your repo →Where its data comes from
An endpoint doesn't store data of its own. It serves whatever its query returns, shaped by the variables you pass and the way it's executed.
Insights
Publish a saved insight as an endpoint and serve the same numbers your dashboards show.
Endpoint types →SQL queries
Write SQL against your events, persons, and data warehouse tables, then expose the result.
Variables →Materialized tables
Eligible queries are precomputed on a schedule so requests read a table instead of scanning events.
How materialization works →Execution logs
Every run records its duration, row count, cache path, and error, across all versions.
Usage and logs →How Endpoints works with Self-driving
Endpoint runs are a signal source for Self-driving. When an execution fails, or a breakdown returns an "Other" bucket because it hit the breakdown limit, Endpoints raises a signal carrying the query, the version, and the error, so whatever picks it up can reason about the cause instead of guessing.
There's no endpoints-specific scout, so these signals fill the inbox rather than trigger an automatic fix. You read the report in the Self-driving inbox or in PostHog Desktop, and decide from there – an endpoint failure never opens a pull request on its own. See the Self-driving docs for the full picture.