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.
Want to see one in production? Our MCP leaderboard is powered by two endpoints. See public stats pages for how it works.
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 →