[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill-posthog-creating-an-endpoint":3,"mdc-i1jlxe-key":45,"related-org-posthog-creating-an-endpoint":1145,"related-repo-posthog-creating-an-endpoint":1308},{"slug":4,"name":4,"fn":5,"description":6,"org":7,"tags":11,"stars":20,"repoUrl":21,"updatedAt":22,"license":23,"forks":24,"topics":25,"repo":40,"sourceUrl":43,"mdContent":44},"creating-an-endpoint","create PostHog API endpoints","Create a PostHog endpoint with the right shape on the first try — covers query kind choice, name conventions, what to expose as variables (HogQL code_name vs insight breakdown), data_freshness_seconds, and whether to materialise on day one. Use when the user says \"create an endpoint\", \"expose this query as an API\", \"turn this insight into an endpoint\", or asks for help structuring a new endpoint. Steers away from common mistakes: materialising a query with cohort breakdowns or compare mode, inline-only variables on a materialised endpoint, unbounded date ranges, ambiguous names.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},"posthog","PostHog","https:\u002F\u002Fpexgzepcugksgbtrxkhf.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Forg-logos\u002Fposthog.png",[12,14,17],{"name":9,"slug":8,"type":13},"tag",{"name":15,"slug":16,"type":13},"Analytics","analytics",{"name":18,"slug":19,"type":13},"API Development","api-development",35568,"https:\u002F\u002Fgithub.com\u002FPostHog\u002Fposthog","2026-06-08T08:08:29.624498",null,2977,[26,27,16,28,29,30,31,32,33,34,35,36,37,38,39],"ab-testing","ai-analytics","cdp","data-warehouse","experiments","feature-flags","javascript","product-analytics","python","react","session-replay","surveys","typescript","web-analytics",{"repoUrl":21,"stars":20,"forks":24,"topics":41,"description":42},[26,27,16,28,29,30,31,32,33,34,35,36,37,38,39],"🦔 PostHog is an all-in-one developer platform for building successful products. We offer product analytics, web analytics, session replay, error tracking, feature flags, experimentation, surveys, data warehouse, a CDP, and an AI product assistant to help debug your code, ship features faster, and keep all your usage and customer data in one stack.","https:\u002F\u002Fgithub.com\u002FPostHog\u002Fposthog\u002Ftree\u002FHEAD\u002Fproducts\u002Fendpoints\u002Fskills\u002Fcreating-an-endpoint","---\nname: creating-an-endpoint\ndescription: >\n  Create a PostHog endpoint with the right shape on the first try — covers query kind choice, name\n  conventions, what to expose as variables (HogQL code_name vs insight breakdown),\n  data_freshness_seconds, and whether to materialise on day one. Use when the user says \"create an endpoint\", \"expose this\n  query as an API\", \"turn this insight into an endpoint\", or asks for help structuring a new\n  endpoint. Steers away from common mistakes: materialising a query with cohort breakdowns or\n  compare mode, inline-only variables on a materialised endpoint, unbounded date ranges, ambiguous\n  names.\n---\n\n# Creating an endpoint\n\nThis skill walks through creating a new endpoint with the right configuration. Endpoints expose\nsaved HogQL or insight queries as callable HTTP routes — the configuration choices made at\ncreation time determine cost, latency, and how callers integrate.\n\nThe materialisation deep-dive lives at `references\u002Fmaterializing.md`. Pull it in when the\nmaterialisation decision is non-obvious.\n\n## When to use this skill\n\n- \"Create an endpoint for [query]\"\n- \"Expose this insight as an API\"\n- \"Help me turn this HogQL into a callable endpoint\"\n- A new caller (mobile app, customer-facing dashboard, downstream pipeline) needs PostHog data\n  and the user is choosing how to deliver it\n\n## Decisions to make in order\n\n### 1. Should this even be an endpoint?\n\nEndpoints are right when:\n\n- An **external system** (someone else's code) needs to call PostHog for data\n- The query is **stable** — not exploratory analysis\n- The shape is **reusable** — same query with different parameters\n\nEndpoints are wrong when:\n\n- An internal PostHog dashboard or insight needs the data — use the insight directly; an endpoint\n  only adds an external API surface you don't need internally\n- One-off, exploratory analysis — use the `execute-sql` tool (or the SQL editor) directly\n\nHeavy aggregation is **not** a reason to avoid an endpoint. Endpoints are themselves saved\nqueries, and a heavy, frequently-called aggregation is often the _best_ case for an endpoint with\nmaterialisation turned on.\n\nIf the user is unsure, ask what's calling the endpoint and what shape they expect.\n\n### 2. Pick a name\n\nNames are URL-safe (letters, numbers, hyphens, underscores), start with a letter, max 128 chars,\nmust be unique within the project. Lean toward:\n\n- **Descriptive over generic** — `weekly_active_users_by_org` over `metrics`\n- **Snake_case** — matches how the name appears in code paths and URLs\n- **No version in the name** — versions are managed by the endpoint itself\n- **No \"endpoint\" in the name** — redundant\n\nThe name appears in the URL: `\u002Fapi\u002Fprojects\u002F{team_id}\u002Fendpoints\u002F{name}\u002Frun`. It's not\ntrivially renameable later (callers depend on the path) — get it right at creation.\n\n### 3. Pick the query kind\n\nTwo options exist:\n\n- **HogQL** (`HogQLQuery`) — raw SQL written by the user. Variables defined via `{variables.x}`\n  syntax, matched on `code_name`. Recommended for new endpoints when the caller cares about\n  the exact column shape of the response.\n- **Insight** — wraps an existing insight definition. Best supported for `TrendsQuery`,\n  `LifecycleQuery`, and `RetentionQuery`: these can be materialised, and the breakdown can act as\n  a variable (Trends and Retention only; Lifecycle has no breakdown). Other insight kinds such as\n  `FunnelsQuery` can run inline but **cannot be materialised and don't expose breakdown\n  variables** — rewrite those as HogQL if you need either.\n\nHogQL is the more flexible choice. Pick insight only when the user is genuinely re-publishing an\nexisting insight (see \"Creating from an existing insight\" below) rather than building a new query.\n\n### 4. Decide which inputs become variables\n\nAnything that should change per-caller goes in variables; the rest is hard-coded in the query.\n\n**For HogQL endpoints**, variables are declared in the query payload with `code_name`, `type`,\nand `default`. Each execution call passes `{ \"variables\": { \"\u003Ccode_name>\": value } }`.\n\nCommon patterns:\n\n- Time windows: `date_from`, `date_to`, or a single `lookback_days` integer\n- Identity filters: `user_id`, `account_id`, `team_id`\n- Pagination control beyond `limit` \u002F `offset` (these are first-class on the run endpoint already)\n\n**For insight endpoints**, the breakdown property acts as the variable (Trends and Retention\nonly — Lifecycle has no breakdown). Pass the breakdown property name as the key. `date_from` \u002F\n`date_to` are accepted as variables **only on non-materialised** insight endpoints — a materialised\nendpoint bakes its date range into the view, so callers can't shift the window.\n\nAvoid:\n\n- **Variables that change the shape of the result** — keep the columns stable. If callers need\n  fundamentally different result shapes, ship separate endpoints.\n- **Variables that bypass safety** — don't expose a `where_clause` variable that lets callers\n  inject arbitrary SQL.\n\n### Creating from an existing insight\n\nThere's no server-side \"make an endpoint from insight N\" operation. To do it: read the insight's\nquery (via the insight tools), pass that query to `endpoint-create`, and set `derived_from_insight`\nto the insight's short id so the origin is recorded. The endpoint then owns its own **copy** of\nthe query — later edits to the insight don't propagate. Starting from scratch instead? Build the\nquery first with the insight \u002F `sql-variables` tools, then create the endpoint from it.\n\n### 5. Set `data_freshness_seconds`\n\nThis one field does **two** jobs, so set it deliberately:\n\n1. **Cache TTL** — results are served from cache until they're this many seconds old.\n2. **Materialisation refresh frequency** — on a materialised endpoint, this is also how often the\n   warehouse recomputes the materialised view.\n\nSo a lower value means fresher data _and_ more frequent recompute\u002Frefresh cost; a higher value is\ncheaper on both counts but staler.\n\nThe value must be one of a fixed set: `900` (15 min), `1800` (30 min), `3600` (1 h), `21600`\n(6 h), `43200` (12 h), `86400` (24 h, default), `604800` (7 d). There is no sub-15-minute\noption — `900` is the floor.\n\n| `data_freshness_seconds` | When to pick it                                                      |\n| ------------------------ | -------------------------------------------------------------------- |\n| 900–1800                 | Freshest available — dashboards where staleness is visible           |\n| 3600–43200               | Most cases — fresh enough for product usage, cheap to recompute      |\n| 86400–604800             | Reports, weekly\u002Fdaily metrics, anything aggregated over long periods |\n\nBias toward higher values unless the user explicitly needs fresher data. On a materialised\nendpoint, remember this also sets the refresh cadence.\n\n### 6. Decide on day-one materialisation\n\nSee `references\u002Fmaterializing.md` for the full decision tree. Short version:\n\n- **Recommend materialisation** when the endpoint will be called frequently, latency matters,\n  and the user can tolerate staleness equal to the refresh interval (typically 5-15 minutes for\n  scheduled materialisation, or hourly).\n- **Skip materialisation** for low-traffic endpoints, exploratory new endpoints (you don't\n  know yet if it'll get called), and queries where freshness is critical.\n\nIf unsure, create unmaterialised and add `is_materialized: true` later once usage stabilises.\nThat avoids paying for materialisation on a query nobody ends up calling.\n\n## Workflow\n\n1. Confirm the use case (step 1 above). If it's not actually a fit for an endpoint, recommend\n   the alternative.\n2. Agree a name with the user.\n3. Walk through the query — confirm it's HogQL or insight, and that the columns\u002Fshape make sense.\n4. Identify what should be a variable. Show the user the variable declaration syntax.\n5. Pick `data_freshness_seconds` based on the user's freshness requirement (ask if not clear) —\n   remembering it also sets the materialisation refresh cadence.\n6. Make the materialisation call. If on the fence, ship without and revisit later.\n7. Call `endpoint-create` with the agreed config.\n8. Confirm by calling `endpoint-run` with a sample payload to verify the response shape.\n9. Hand off to `consuming-endpoints-from-client-code` if the user is about to wire it up.\n\n## Example interaction\n\n```text\nUser: \"I want to expose our monthly active users count as an API\n       for our analytics partner\"\n\nAgent:\n- \"Quick check: is the partner going to call this on demand, or\n   should we be pushing data to them? Endpoints are pull-only.\"\n- User: \"On demand\"\n- \"Got it. A few choices:\n   - Name: how about monthly_active_users? Lowercase, descriptive,\n     no version baggage.\n   - The query — is it HogQL or are you exposing an existing insight?\n     HogQL gives you exact column control; insight reuses what you've\n     already built.\n   - What should the partner be able to filter by? Org, time window,\n     both?\n   - How fresh? If MAU drifts within a day is fine, we can cache\n     results for 1-24 hours and serve almost everything from cache.\n   - Materialisation: if the partner is going to hit this many times\n     per day, materialising it would make responses near-instant.\n     The trade-off is ~10-15 minute staleness.\n\n   What's your starting point on these?\"\n\n[user picks: HogQL, lookback_days + org_id variables, 3600s TTL,\n not materialised yet]\n\n- endpoint-create monthly_active_users {query, variables, ...}\n- endpoint-run with sample payload {org_id: \"test\", lookback_days: 30}\n- \"Created and tested. Want help wiring up the client code?\n   That's consuming-endpoints-from-client-code.\"\n```\n\n## Important notes\n\n- **The name lives in the URL.** Changing it later requires migrating callers. Pick well.\n- **HogQL endpoints are more flexible than insight endpoints.** Default to HogQL unless the\n  user has a specific reason to wrap an existing insight.\n- **Variables with no default fail at call time.** Always set defaults during creation so the\n  endpoint is testable from the playground without specifying every variable.\n- **Materialised endpoints require all variables to be passed.** Calls without them are\n  rejected — this is intentional (security: prevents returning unfiltered data). Pair the\n  materialisation recommendation with a note to the user about which variables become required.\n  (Optional\u002Fpartial variables on materialised endpoints are a known limitation the PostHog team\n  plans to lift — if it's blocking the user, nudge them via the `agent-feedback` tool.)\n- **Don't enable materialisation on a query that isn't eligible.** Use\n  `endpoints-materialization-preview` first to confirm eligibility and see the rejection reason\n  if any.\n- **Endpoints are not stable forever.** When the user changes the query, a new version is created\n  automatically (the old version stays accessible via `?version=N`). `data_freshness_seconds` and\n  materialisation are per-version. Adjust as the endpoint evolves.\n- **Recommend callers pin to a version.** Tell the user to call with `?version=N` rather than\n  relying on \"latest\" — that way a future query edit (which cuts a new version) can't silently\n  change their results. They bump the pinned version deliberately once they've validated the new\n  one.\n- **Share friction via `agent-feedback`.** If a limitation gets in the way (eligibility rules,\n  required variables, the TTL enum), send the PostHog team a note — it's how the product and these\n  tools improve.\n",{"data":46,"body":47},{"name":4,"description":6},{"type":48,"children":49},"root",[50,58,64,78,85,118,124,131,136,176,181,202,222,227,233,238,295,308,314,319,405,410,416,421,462,467,544,575,580,611,617,653,665,677,701,713,781,851,856,862,874,897,910,916,994,1000,1012,1018],{"type":51,"tag":52,"props":53,"children":54},"element","h1",{"id":4},[55],{"type":56,"value":57},"text","Creating an endpoint",{"type":51,"tag":59,"props":60,"children":61},"p",{},[62],{"type":56,"value":63},"This skill walks through creating a new endpoint with the right configuration. Endpoints expose\nsaved HogQL or insight queries as callable HTTP routes — the configuration choices made at\ncreation time determine cost, latency, and how callers integrate.",{"type":51,"tag":59,"props":65,"children":66},{},[67,69,76],{"type":56,"value":68},"The materialisation deep-dive lives at ",{"type":51,"tag":70,"props":71,"children":73},"code",{"className":72},[],[74],{"type":56,"value":75},"references\u002Fmaterializing.md",{"type":56,"value":77},". Pull it in when the\nmaterialisation decision is non-obvious.",{"type":51,"tag":79,"props":80,"children":82},"h2",{"id":81},"when-to-use-this-skill",[83],{"type":56,"value":84},"When to use this skill",{"type":51,"tag":86,"props":87,"children":88},"ul",{},[89,103,108,113],{"type":51,"tag":90,"props":91,"children":92},"li",{},[93,95,101],{"type":56,"value":94},"\"Create an endpoint for ",{"type":51,"tag":96,"props":97,"children":98},"span",{},[99],{"type":56,"value":100},"query",{"type":56,"value":102},"\"",{"type":51,"tag":90,"props":104,"children":105},{},[106],{"type":56,"value":107},"\"Expose this insight as an API\"",{"type":51,"tag":90,"props":109,"children":110},{},[111],{"type":56,"value":112},"\"Help me turn this HogQL into a callable endpoint\"",{"type":51,"tag":90,"props":114,"children":115},{},[116],{"type":56,"value":117},"A new caller (mobile app, customer-facing dashboard, downstream pipeline) needs PostHog data\nand the user is choosing how to deliver it",{"type":51,"tag":79,"props":119,"children":121},{"id":120},"decisions-to-make-in-order",[122],{"type":56,"value":123},"Decisions to make in order",{"type":51,"tag":125,"props":126,"children":128},"h3",{"id":127},"_1-should-this-even-be-an-endpoint",[129],{"type":56,"value":130},"1. Should this even be an endpoint?",{"type":51,"tag":59,"props":132,"children":133},{},[134],{"type":56,"value":135},"Endpoints are right when:",{"type":51,"tag":86,"props":137,"children":138},{},[139,152,164],{"type":51,"tag":90,"props":140,"children":141},{},[142,144,150],{"type":56,"value":143},"An ",{"type":51,"tag":145,"props":146,"children":147},"strong",{},[148],{"type":56,"value":149},"external system",{"type":56,"value":151}," (someone else's code) needs to call PostHog for data",{"type":51,"tag":90,"props":153,"children":154},{},[155,157,162],{"type":56,"value":156},"The query is ",{"type":51,"tag":145,"props":158,"children":159},{},[160],{"type":56,"value":161},"stable",{"type":56,"value":163}," — not exploratory analysis",{"type":51,"tag":90,"props":165,"children":166},{},[167,169,174],{"type":56,"value":168},"The shape is ",{"type":51,"tag":145,"props":170,"children":171},{},[172],{"type":56,"value":173},"reusable",{"type":56,"value":175}," — same query with different parameters",{"type":51,"tag":59,"props":177,"children":178},{},[179],{"type":56,"value":180},"Endpoints are wrong when:",{"type":51,"tag":86,"props":182,"children":183},{},[184,189],{"type":51,"tag":90,"props":185,"children":186},{},[187],{"type":56,"value":188},"An internal PostHog dashboard or insight needs the data — use the insight directly; an endpoint\nonly adds an external API surface you don't need internally",{"type":51,"tag":90,"props":190,"children":191},{},[192,194,200],{"type":56,"value":193},"One-off, exploratory analysis — use the ",{"type":51,"tag":70,"props":195,"children":197},{"className":196},[],[198],{"type":56,"value":199},"execute-sql",{"type":56,"value":201}," tool (or the SQL editor) directly",{"type":51,"tag":59,"props":203,"children":204},{},[205,207,212,214,220],{"type":56,"value":206},"Heavy aggregation is ",{"type":51,"tag":145,"props":208,"children":209},{},[210],{"type":56,"value":211},"not",{"type":56,"value":213}," a reason to avoid an endpoint. Endpoints are themselves saved\nqueries, and a heavy, frequently-called aggregation is often the ",{"type":51,"tag":215,"props":216,"children":217},"em",{},[218],{"type":56,"value":219},"best",{"type":56,"value":221}," case for an endpoint with\nmaterialisation turned on.",{"type":51,"tag":59,"props":223,"children":224},{},[225],{"type":56,"value":226},"If the user is unsure, ask what's calling the endpoint and what shape they expect.",{"type":51,"tag":125,"props":228,"children":230},{"id":229},"_2-pick-a-name",[231],{"type":56,"value":232},"2. Pick a name",{"type":51,"tag":59,"props":234,"children":235},{},[236],{"type":56,"value":237},"Names are URL-safe (letters, numbers, hyphens, underscores), start with a letter, max 128 chars,\nmust be unique within the project. Lean toward:",{"type":51,"tag":86,"props":239,"children":240},{},[241,265,275,285],{"type":51,"tag":90,"props":242,"children":243},{},[244,249,251,257,259],{"type":51,"tag":145,"props":245,"children":246},{},[247],{"type":56,"value":248},"Descriptive over generic",{"type":56,"value":250}," — ",{"type":51,"tag":70,"props":252,"children":254},{"className":253},[],[255],{"type":56,"value":256},"weekly_active_users_by_org",{"type":56,"value":258}," over ",{"type":51,"tag":70,"props":260,"children":262},{"className":261},[],[263],{"type":56,"value":264},"metrics",{"type":51,"tag":90,"props":266,"children":267},{},[268,273],{"type":51,"tag":145,"props":269,"children":270},{},[271],{"type":56,"value":272},"Snake_case",{"type":56,"value":274}," — matches how the name appears in code paths and URLs",{"type":51,"tag":90,"props":276,"children":277},{},[278,283],{"type":51,"tag":145,"props":279,"children":280},{},[281],{"type":56,"value":282},"No version in the name",{"type":56,"value":284}," — versions are managed by the endpoint itself",{"type":51,"tag":90,"props":286,"children":287},{},[288,293],{"type":51,"tag":145,"props":289,"children":290},{},[291],{"type":56,"value":292},"No \"endpoint\" in the name",{"type":56,"value":294}," — redundant",{"type":51,"tag":59,"props":296,"children":297},{},[298,300,306],{"type":56,"value":299},"The name appears in the URL: ",{"type":51,"tag":70,"props":301,"children":303},{"className":302},[],[304],{"type":56,"value":305},"\u002Fapi\u002Fprojects\u002F{team_id}\u002Fendpoints\u002F{name}\u002Frun",{"type":56,"value":307},". It's not\ntrivially renameable later (callers depend on the path) — get it right at creation.",{"type":51,"tag":125,"props":309,"children":311},{"id":310},"_3-pick-the-query-kind",[312],{"type":56,"value":313},"3. Pick the query kind",{"type":51,"tag":59,"props":315,"children":316},{},[317],{"type":56,"value":318},"Two options exist:",{"type":51,"tag":86,"props":320,"children":321},{},[322,356],{"type":51,"tag":90,"props":323,"children":324},{},[325,330,332,338,340,346,348,354],{"type":51,"tag":145,"props":326,"children":327},{},[328],{"type":56,"value":329},"HogQL",{"type":56,"value":331}," (",{"type":51,"tag":70,"props":333,"children":335},{"className":334},[],[336],{"type":56,"value":337},"HogQLQuery",{"type":56,"value":339},") — raw SQL written by the user. Variables defined via ",{"type":51,"tag":70,"props":341,"children":343},{"className":342},[],[344],{"type":56,"value":345},"{variables.x}",{"type":56,"value":347},"\nsyntax, matched on ",{"type":51,"tag":70,"props":349,"children":351},{"className":350},[],[352],{"type":56,"value":353},"code_name",{"type":56,"value":355},". Recommended for new endpoints when the caller cares about\nthe exact column shape of the response.",{"type":51,"tag":90,"props":357,"children":358},{},[359,364,366,372,374,380,382,388,390,396,398,403],{"type":51,"tag":145,"props":360,"children":361},{},[362],{"type":56,"value":363},"Insight",{"type":56,"value":365}," — wraps an existing insight definition. Best supported for ",{"type":51,"tag":70,"props":367,"children":369},{"className":368},[],[370],{"type":56,"value":371},"TrendsQuery",{"type":56,"value":373},",\n",{"type":51,"tag":70,"props":375,"children":377},{"className":376},[],[378],{"type":56,"value":379},"LifecycleQuery",{"type":56,"value":381},", and ",{"type":51,"tag":70,"props":383,"children":385},{"className":384},[],[386],{"type":56,"value":387},"RetentionQuery",{"type":56,"value":389},": these can be materialised, and the breakdown can act as\na variable (Trends and Retention only; Lifecycle has no breakdown). Other insight kinds such as\n",{"type":51,"tag":70,"props":391,"children":393},{"className":392},[],[394],{"type":56,"value":395},"FunnelsQuery",{"type":56,"value":397}," can run inline but ",{"type":51,"tag":145,"props":399,"children":400},{},[401],{"type":56,"value":402},"cannot be materialised and don't expose breakdown\nvariables",{"type":56,"value":404}," — rewrite those as HogQL if you need either.",{"type":51,"tag":59,"props":406,"children":407},{},[408],{"type":56,"value":409},"HogQL is the more flexible choice. Pick insight only when the user is genuinely re-publishing an\nexisting insight (see \"Creating from an existing insight\" below) rather than building a new query.",{"type":51,"tag":125,"props":411,"children":413},{"id":412},"_4-decide-which-inputs-become-variables",[414],{"type":56,"value":415},"4. Decide which inputs become variables",{"type":51,"tag":59,"props":417,"children":418},{},[419],{"type":56,"value":420},"Anything that should change per-caller goes in variables; the rest is hard-coded in the query.",{"type":51,"tag":59,"props":422,"children":423},{},[424,429,431,436,438,444,446,452,454,460],{"type":51,"tag":145,"props":425,"children":426},{},[427],{"type":56,"value":428},"For HogQL endpoints",{"type":56,"value":430},", variables are declared in the query payload with ",{"type":51,"tag":70,"props":432,"children":434},{"className":433},[],[435],{"type":56,"value":353},{"type":56,"value":437},", ",{"type":51,"tag":70,"props":439,"children":441},{"className":440},[],[442],{"type":56,"value":443},"type",{"type":56,"value":445},",\nand ",{"type":51,"tag":70,"props":447,"children":449},{"className":448},[],[450],{"type":56,"value":451},"default",{"type":56,"value":453},". Each execution call passes ",{"type":51,"tag":70,"props":455,"children":457},{"className":456},[],[458],{"type":56,"value":459},"{ \"variables\": { \"\u003Ccode_name>\": value } }",{"type":56,"value":461},".",{"type":51,"tag":59,"props":463,"children":464},{},[465],{"type":56,"value":466},"Common patterns:",{"type":51,"tag":86,"props":468,"children":469},{},[470,498,523],{"type":51,"tag":90,"props":471,"children":472},{},[473,475,481,482,488,490,496],{"type":56,"value":474},"Time windows: ",{"type":51,"tag":70,"props":476,"children":478},{"className":477},[],[479],{"type":56,"value":480},"date_from",{"type":56,"value":437},{"type":51,"tag":70,"props":483,"children":485},{"className":484},[],[486],{"type":56,"value":487},"date_to",{"type":56,"value":489},", or a single ",{"type":51,"tag":70,"props":491,"children":493},{"className":492},[],[494],{"type":56,"value":495},"lookback_days",{"type":56,"value":497}," integer",{"type":51,"tag":90,"props":499,"children":500},{},[501,503,509,510,516,517],{"type":56,"value":502},"Identity filters: ",{"type":51,"tag":70,"props":504,"children":506},{"className":505},[],[507],{"type":56,"value":508},"user_id",{"type":56,"value":437},{"type":51,"tag":70,"props":511,"children":513},{"className":512},[],[514],{"type":56,"value":515},"account_id",{"type":56,"value":437},{"type":51,"tag":70,"props":518,"children":520},{"className":519},[],[521],{"type":56,"value":522},"team_id",{"type":51,"tag":90,"props":524,"children":525},{},[526,528,534,536,542],{"type":56,"value":527},"Pagination control beyond ",{"type":51,"tag":70,"props":529,"children":531},{"className":530},[],[532],{"type":56,"value":533},"limit",{"type":56,"value":535}," \u002F ",{"type":51,"tag":70,"props":537,"children":539},{"className":538},[],[540],{"type":56,"value":541},"offset",{"type":56,"value":543}," (these are first-class on the run endpoint already)",{"type":51,"tag":59,"props":545,"children":546},{},[547,552,554,559,561,566,568,573],{"type":51,"tag":145,"props":548,"children":549},{},[550],{"type":56,"value":551},"For insight endpoints",{"type":56,"value":553},", the breakdown property acts as the variable (Trends and Retention\nonly — Lifecycle has no breakdown). Pass the breakdown property name as the key. ",{"type":51,"tag":70,"props":555,"children":557},{"className":556},[],[558],{"type":56,"value":480},{"type":56,"value":560}," \u002F\n",{"type":51,"tag":70,"props":562,"children":564},{"className":563},[],[565],{"type":56,"value":487},{"type":56,"value":567}," are accepted as variables ",{"type":51,"tag":145,"props":569,"children":570},{},[571],{"type":56,"value":572},"only on non-materialised",{"type":56,"value":574}," insight endpoints — a materialised\nendpoint bakes its date range into the view, so callers can't shift the window.",{"type":51,"tag":59,"props":576,"children":577},{},[578],{"type":56,"value":579},"Avoid:",{"type":51,"tag":86,"props":581,"children":582},{},[583,593],{"type":51,"tag":90,"props":584,"children":585},{},[586,591],{"type":51,"tag":145,"props":587,"children":588},{},[589],{"type":56,"value":590},"Variables that change the shape of the result",{"type":56,"value":592}," — keep the columns stable. If callers need\nfundamentally different result shapes, ship separate endpoints.",{"type":51,"tag":90,"props":594,"children":595},{},[596,601,603,609],{"type":51,"tag":145,"props":597,"children":598},{},[599],{"type":56,"value":600},"Variables that bypass safety",{"type":56,"value":602}," — don't expose a ",{"type":51,"tag":70,"props":604,"children":606},{"className":605},[],[607],{"type":56,"value":608},"where_clause",{"type":56,"value":610}," variable that lets callers\ninject arbitrary SQL.",{"type":51,"tag":125,"props":612,"children":614},{"id":613},"creating-from-an-existing-insight",[615],{"type":56,"value":616},"Creating from an existing insight",{"type":51,"tag":59,"props":618,"children":619},{},[620,622,628,630,636,638,643,645,651],{"type":56,"value":621},"There's no server-side \"make an endpoint from insight N\" operation. To do it: read the insight's\nquery (via the insight tools), pass that query to ",{"type":51,"tag":70,"props":623,"children":625},{"className":624},[],[626],{"type":56,"value":627},"endpoint-create",{"type":56,"value":629},", and set ",{"type":51,"tag":70,"props":631,"children":633},{"className":632},[],[634],{"type":56,"value":635},"derived_from_insight",{"type":56,"value":637},"\nto the insight's short id so the origin is recorded. The endpoint then owns its own ",{"type":51,"tag":145,"props":639,"children":640},{},[641],{"type":56,"value":642},"copy",{"type":56,"value":644}," of\nthe query — later edits to the insight don't propagate. Starting from scratch instead? Build the\nquery first with the insight \u002F ",{"type":51,"tag":70,"props":646,"children":648},{"className":647},[],[649],{"type":56,"value":650},"sql-variables",{"type":56,"value":652}," tools, then create the endpoint from it.",{"type":51,"tag":125,"props":654,"children":656},{"id":655},"_5-set-data_freshness_seconds",[657,659],{"type":56,"value":658},"5. Set ",{"type":51,"tag":70,"props":660,"children":662},{"className":661},[],[663],{"type":56,"value":664},"data_freshness_seconds",{"type":51,"tag":59,"props":666,"children":667},{},[668,670,675],{"type":56,"value":669},"This one field does ",{"type":51,"tag":145,"props":671,"children":672},{},[673],{"type":56,"value":674},"two",{"type":56,"value":676}," jobs, so set it deliberately:",{"type":51,"tag":678,"props":679,"children":680},"ol",{},[681,691],{"type":51,"tag":90,"props":682,"children":683},{},[684,689],{"type":51,"tag":145,"props":685,"children":686},{},[687],{"type":56,"value":688},"Cache TTL",{"type":56,"value":690}," — results are served from cache until they're this many seconds old.",{"type":51,"tag":90,"props":692,"children":693},{},[694,699],{"type":51,"tag":145,"props":695,"children":696},{},[697],{"type":56,"value":698},"Materialisation refresh frequency",{"type":56,"value":700}," — on a materialised endpoint, this is also how often the\nwarehouse recomputes the materialised view.",{"type":51,"tag":59,"props":702,"children":703},{},[704,706,711],{"type":56,"value":705},"So a lower value means fresher data ",{"type":51,"tag":215,"props":707,"children":708},{},[709],{"type":56,"value":710},"and",{"type":56,"value":712}," more frequent recompute\u002Frefresh cost; a higher value is\ncheaper on both counts but staler.",{"type":51,"tag":59,"props":714,"children":715},{},[716,718,724,726,732,734,740,742,748,750,756,758,764,766,772,774,779],{"type":56,"value":717},"The value must be one of a fixed set: ",{"type":51,"tag":70,"props":719,"children":721},{"className":720},[],[722],{"type":56,"value":723},"900",{"type":56,"value":725}," (15 min), ",{"type":51,"tag":70,"props":727,"children":729},{"className":728},[],[730],{"type":56,"value":731},"1800",{"type":56,"value":733}," (30 min), ",{"type":51,"tag":70,"props":735,"children":737},{"className":736},[],[738],{"type":56,"value":739},"3600",{"type":56,"value":741}," (1 h), ",{"type":51,"tag":70,"props":743,"children":745},{"className":744},[],[746],{"type":56,"value":747},"21600",{"type":56,"value":749},"\n(6 h), ",{"type":51,"tag":70,"props":751,"children":753},{"className":752},[],[754],{"type":56,"value":755},"43200",{"type":56,"value":757}," (12 h), ",{"type":51,"tag":70,"props":759,"children":761},{"className":760},[],[762],{"type":56,"value":763},"86400",{"type":56,"value":765}," (24 h, default), ",{"type":51,"tag":70,"props":767,"children":769},{"className":768},[],[770],{"type":56,"value":771},"604800",{"type":56,"value":773}," (7 d). There is no sub-15-minute\noption — ",{"type":51,"tag":70,"props":775,"children":777},{"className":776},[],[778],{"type":56,"value":723},{"type":56,"value":780}," is the floor.",{"type":51,"tag":782,"props":783,"children":784},"table",{},[785,807],{"type":51,"tag":786,"props":787,"children":788},"thead",{},[789],{"type":51,"tag":790,"props":791,"children":792},"tr",{},[793,802],{"type":51,"tag":794,"props":795,"children":796},"th",{},[797],{"type":51,"tag":70,"props":798,"children":800},{"className":799},[],[801],{"type":56,"value":664},{"type":51,"tag":794,"props":803,"children":804},{},[805],{"type":56,"value":806},"When to pick it",{"type":51,"tag":808,"props":809,"children":810},"tbody",{},[811,825,838],{"type":51,"tag":790,"props":812,"children":813},{},[814,820],{"type":51,"tag":815,"props":816,"children":817},"td",{},[818],{"type":56,"value":819},"900–1800",{"type":51,"tag":815,"props":821,"children":822},{},[823],{"type":56,"value":824},"Freshest available — dashboards where staleness is visible",{"type":51,"tag":790,"props":826,"children":827},{},[828,833],{"type":51,"tag":815,"props":829,"children":830},{},[831],{"type":56,"value":832},"3600–43200",{"type":51,"tag":815,"props":834,"children":835},{},[836],{"type":56,"value":837},"Most cases — fresh enough for product usage, cheap to recompute",{"type":51,"tag":790,"props":839,"children":840},{},[841,846],{"type":51,"tag":815,"props":842,"children":843},{},[844],{"type":56,"value":845},"86400–604800",{"type":51,"tag":815,"props":847,"children":848},{},[849],{"type":56,"value":850},"Reports, weekly\u002Fdaily metrics, anything aggregated over long periods",{"type":51,"tag":59,"props":852,"children":853},{},[854],{"type":56,"value":855},"Bias toward higher values unless the user explicitly needs fresher data. On a materialised\nendpoint, remember this also sets the refresh cadence.",{"type":51,"tag":125,"props":857,"children":859},{"id":858},"_6-decide-on-day-one-materialisation",[860],{"type":56,"value":861},"6. Decide on day-one materialisation",{"type":51,"tag":59,"props":863,"children":864},{},[865,867,872],{"type":56,"value":866},"See ",{"type":51,"tag":70,"props":868,"children":870},{"className":869},[],[871],{"type":56,"value":75},{"type":56,"value":873}," for the full decision tree. Short version:",{"type":51,"tag":86,"props":875,"children":876},{},[877,887],{"type":51,"tag":90,"props":878,"children":879},{},[880,885],{"type":51,"tag":145,"props":881,"children":882},{},[883],{"type":56,"value":884},"Recommend materialisation",{"type":56,"value":886}," when the endpoint will be called frequently, latency matters,\nand the user can tolerate staleness equal to the refresh interval (typically 5-15 minutes for\nscheduled materialisation, or hourly).",{"type":51,"tag":90,"props":888,"children":889},{},[890,895],{"type":51,"tag":145,"props":891,"children":892},{},[893],{"type":56,"value":894},"Skip materialisation",{"type":56,"value":896}," for low-traffic endpoints, exploratory new endpoints (you don't\nknow yet if it'll get called), and queries where freshness is critical.",{"type":51,"tag":59,"props":898,"children":899},{},[900,902,908],{"type":56,"value":901},"If unsure, create unmaterialised and add ",{"type":51,"tag":70,"props":903,"children":905},{"className":904},[],[906],{"type":56,"value":907},"is_materialized: true",{"type":56,"value":909}," later once usage stabilises.\nThat avoids paying for materialisation on a query nobody ends up calling.",{"type":51,"tag":79,"props":911,"children":913},{"id":912},"workflow",[914],{"type":56,"value":915},"Workflow",{"type":51,"tag":678,"props":917,"children":918},{},[919,924,929,934,939,951,956,968,981],{"type":51,"tag":90,"props":920,"children":921},{},[922],{"type":56,"value":923},"Confirm the use case (step 1 above). If it's not actually a fit for an endpoint, recommend\nthe alternative.",{"type":51,"tag":90,"props":925,"children":926},{},[927],{"type":56,"value":928},"Agree a name with the user.",{"type":51,"tag":90,"props":930,"children":931},{},[932],{"type":56,"value":933},"Walk through the query — confirm it's HogQL or insight, and that the columns\u002Fshape make sense.",{"type":51,"tag":90,"props":935,"children":936},{},[937],{"type":56,"value":938},"Identify what should be a variable. Show the user the variable declaration syntax.",{"type":51,"tag":90,"props":940,"children":941},{},[942,944,949],{"type":56,"value":943},"Pick ",{"type":51,"tag":70,"props":945,"children":947},{"className":946},[],[948],{"type":56,"value":664},{"type":56,"value":950}," based on the user's freshness requirement (ask if not clear) —\nremembering it also sets the materialisation refresh cadence.",{"type":51,"tag":90,"props":952,"children":953},{},[954],{"type":56,"value":955},"Make the materialisation call. If on the fence, ship without and revisit later.",{"type":51,"tag":90,"props":957,"children":958},{},[959,961,966],{"type":56,"value":960},"Call ",{"type":51,"tag":70,"props":962,"children":964},{"className":963},[],[965],{"type":56,"value":627},{"type":56,"value":967}," with the agreed config.",{"type":51,"tag":90,"props":969,"children":970},{},[971,973,979],{"type":56,"value":972},"Confirm by calling ",{"type":51,"tag":70,"props":974,"children":976},{"className":975},[],[977],{"type":56,"value":978},"endpoint-run",{"type":56,"value":980}," with a sample payload to verify the response shape.",{"type":51,"tag":90,"props":982,"children":983},{},[984,986,992],{"type":56,"value":985},"Hand off to ",{"type":51,"tag":70,"props":987,"children":989},{"className":988},[],[990],{"type":56,"value":991},"consuming-endpoints-from-client-code",{"type":56,"value":993}," if the user is about to wire it up.",{"type":51,"tag":79,"props":995,"children":997},{"id":996},"example-interaction",[998],{"type":56,"value":999},"Example interaction",{"type":51,"tag":1001,"props":1002,"children":1007},"pre",{"className":1003,"code":1005,"language":56,"meta":1006},[1004],"language-text","User: \"I want to expose our monthly active users count as an API\n       for our analytics partner\"\n\nAgent:\n- \"Quick check: is the partner going to call this on demand, or\n   should we be pushing data to them? Endpoints are pull-only.\"\n- User: \"On demand\"\n- \"Got it. A few choices:\n   - Name: how about monthly_active_users? Lowercase, descriptive,\n     no version baggage.\n   - The query — is it HogQL or are you exposing an existing insight?\n     HogQL gives you exact column control; insight reuses what you've\n     already built.\n   - What should the partner be able to filter by? Org, time window,\n     both?\n   - How fresh? If MAU drifts within a day is fine, we can cache\n     results for 1-24 hours and serve almost everything from cache.\n   - Materialisation: if the partner is going to hit this many times\n     per day, materialising it would make responses near-instant.\n     The trade-off is ~10-15 minute staleness.\n\n   What's your starting point on these?\"\n\n[user picks: HogQL, lookback_days + org_id variables, 3600s TTL,\n not materialised yet]\n\n- endpoint-create monthly_active_users {query, variables, ...}\n- endpoint-run with sample payload {org_id: \"test\", lookback_days: 30}\n- \"Created and tested. Want help wiring up the client code?\n   That's consuming-endpoints-from-client-code.\"\n","",[1008],{"type":51,"tag":70,"props":1009,"children":1010},{"__ignoreMap":1006},[1011],{"type":56,"value":1005},{"type":51,"tag":79,"props":1013,"children":1015},{"id":1014},"important-notes",[1016],{"type":56,"value":1017},"Important notes",{"type":51,"tag":86,"props":1019,"children":1020},{},[1021,1031,1041,1051,1069,1087,1112,1129],{"type":51,"tag":90,"props":1022,"children":1023},{},[1024,1029],{"type":51,"tag":145,"props":1025,"children":1026},{},[1027],{"type":56,"value":1028},"The name lives in the URL.",{"type":56,"value":1030}," Changing it later requires migrating callers. Pick well.",{"type":51,"tag":90,"props":1032,"children":1033},{},[1034,1039],{"type":51,"tag":145,"props":1035,"children":1036},{},[1037],{"type":56,"value":1038},"HogQL endpoints are more flexible than insight endpoints.",{"type":56,"value":1040}," Default to HogQL unless the\nuser has a specific reason to wrap an existing insight.",{"type":51,"tag":90,"props":1042,"children":1043},{},[1044,1049],{"type":51,"tag":145,"props":1045,"children":1046},{},[1047],{"type":56,"value":1048},"Variables with no default fail at call time.",{"type":56,"value":1050}," Always set defaults during creation so the\nendpoint is testable from the playground without specifying every variable.",{"type":51,"tag":90,"props":1052,"children":1053},{},[1054,1059,1061,1067],{"type":51,"tag":145,"props":1055,"children":1056},{},[1057],{"type":56,"value":1058},"Materialised endpoints require all variables to be passed.",{"type":56,"value":1060}," Calls without them are\nrejected — this is intentional (security: prevents returning unfiltered data). Pair the\nmaterialisation recommendation with a note to the user about which variables become required.\n(Optional\u002Fpartial variables on materialised endpoints are a known limitation the PostHog team\nplans to lift — if it's blocking the user, nudge them via the ",{"type":51,"tag":70,"props":1062,"children":1064},{"className":1063},[],[1065],{"type":56,"value":1066},"agent-feedback",{"type":56,"value":1068}," tool.)",{"type":51,"tag":90,"props":1070,"children":1071},{},[1072,1077,1079,1085],{"type":51,"tag":145,"props":1073,"children":1074},{},[1075],{"type":56,"value":1076},"Don't enable materialisation on a query that isn't eligible.",{"type":56,"value":1078}," Use\n",{"type":51,"tag":70,"props":1080,"children":1082},{"className":1081},[],[1083],{"type":56,"value":1084},"endpoints-materialization-preview",{"type":56,"value":1086}," first to confirm eligibility and see the rejection reason\nif any.",{"type":51,"tag":90,"props":1088,"children":1089},{},[1090,1095,1097,1103,1105,1110],{"type":51,"tag":145,"props":1091,"children":1092},{},[1093],{"type":56,"value":1094},"Endpoints are not stable forever.",{"type":56,"value":1096}," When the user changes the query, a new version is created\nautomatically (the old version stays accessible via ",{"type":51,"tag":70,"props":1098,"children":1100},{"className":1099},[],[1101],{"type":56,"value":1102},"?version=N",{"type":56,"value":1104},"). ",{"type":51,"tag":70,"props":1106,"children":1108},{"className":1107},[],[1109],{"type":56,"value":664},{"type":56,"value":1111}," and\nmaterialisation are per-version. Adjust as the endpoint evolves.",{"type":51,"tag":90,"props":1113,"children":1114},{},[1115,1120,1122,1127],{"type":51,"tag":145,"props":1116,"children":1117},{},[1118],{"type":56,"value":1119},"Recommend callers pin to a version.",{"type":56,"value":1121}," Tell the user to call with ",{"type":51,"tag":70,"props":1123,"children":1125},{"className":1124},[],[1126],{"type":56,"value":1102},{"type":56,"value":1128}," rather than\nrelying on \"latest\" — that way a future query edit (which cuts a new version) can't silently\nchange their results. They bump the pinned version deliberately once they've validated the new\none.",{"type":51,"tag":90,"props":1130,"children":1131},{},[1132,1143],{"type":51,"tag":145,"props":1133,"children":1134},{},[1135,1137,1142],{"type":56,"value":1136},"Share friction via ",{"type":51,"tag":70,"props":1138,"children":1140},{"className":1139},[],[1141],{"type":56,"value":1066},{"type":56,"value":461},{"type":56,"value":1144}," If a limitation gets in the way (eligibility rules,\nrequired variables, the TTL enum), send the PostHog team a note — it's how the product and these\ntools improve.",{"items":1146,"total":1307},[1147,1162,1174,1186,1199,1214,1230,1247,1261,1273,1283,1301],{"slug":1148,"name":1148,"fn":1149,"description":1150,"org":1151,"tags":1152,"stars":20,"repoUrl":21,"updatedAt":1161},"analyzing-expensive-users","analyze expensive users in AI observability","Analyze the most expensive users in AI observability and explain why they cost so much. Use when the user asks about top spenders, expensive users, per-user LLM cost, user-level cost drivers, or patterns behind high AI observability spend.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1153,1154,1157,1160],{"name":15,"slug":16,"type":13},{"name":1155,"slug":1156,"type":13},"Cost Optimization","cost-optimization",{"name":1158,"slug":1159,"type":13},"Observability","observability",{"name":9,"slug":8,"type":13},"2026-07-28T05:34:11.117757",{"slug":1163,"name":1163,"fn":1164,"description":1165,"org":1166,"tags":1167,"stars":20,"repoUrl":21,"updatedAt":1173},"auditing-endpoints","audit PostHog project endpoints","Audit every endpoint in a PostHog project for staleness, failed materialisations, and unused materialised versions. Use when the user asks \"what endpoints can I clean up?\", \"are any of my endpoints broken?\", \"which materialised versions are still being called?\", or wants a one-shot cleanup pass over the Endpoints product. Produces a prioritised report grouped by issue type, with recommended actions but does not modify anything without explicit confirmation.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1168,1169,1172],{"name":15,"slug":16,"type":13},{"name":1170,"slug":1171,"type":13},"Audit","audit",{"name":9,"slug":8,"type":13},"2026-06-08T08:08:33.693989",{"slug":1175,"name":1175,"fn":1176,"description":1177,"org":1178,"tags":1179,"stars":20,"repoUrl":21,"updatedAt":1185},"auditing-warehouse-source-health","audit PostHog data warehouse source health","Audit the health of a PostHog project's data warehouse sources and syncs — find every broken or degraded source connection, sync schema, and webhook channel. Use when the user asks \"why are my imports failing?\", \"what's broken with my sources?\", \"why is my warehouse data stale?\", or wants a one-shot triage of source\u002Fsync health before deciding where to dig in. Produces a prioritized report grouped by severity, with recommended next steps. For materialized-view health use `auditing-warehouse-view-health`; for a single failing sync use `diagnosing-failed-warehouse-syncs`.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1180,1181,1183,1184],{"name":1170,"slug":1171,"type":13},{"name":1182,"slug":29,"type":13},"Data Warehouse",{"name":1158,"slug":1159,"type":13},{"name":9,"slug":8,"type":13},"2026-06-18T08:22:57.67984",{"slug":1187,"name":1187,"fn":1188,"description":1189,"org":1190,"tags":1191,"stars":20,"repoUrl":21,"updatedAt":1198},"auditing-warehouse-view-health","audit PostHog materialized view health","Audit the health of a PostHog project's materialized views (saved queries) — find every failed materialization and flag unused or stale materialized views that cost storage and compute. Use when the user asks \"which of my views are broken?\", \"why is this materialized view failing?\", \"are any of my views wasting compute?\", or wants a one-shot triage of view health. For source\u002Fsync health use `auditing-warehouse-source-health`.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1192,1193,1194,1197],{"name":1170,"slug":1171,"type":13},{"name":1182,"slug":29,"type":13},{"name":1195,"slug":1196,"type":13},"Performance","performance",{"name":9,"slug":8,"type":13},"2026-06-18T08:25:10.936787",{"slug":1200,"name":1200,"fn":1201,"description":1202,"org":1203,"tags":1204,"stars":20,"repoUrl":21,"updatedAt":1213},"authoring-error-tracking-alerts","author PostHog error tracking alerts","Author error tracking alerts that fire when an issue is created, reopened, or starts spiking. Use when the user asks to set up error notifications, route exceptions to Slack\u002Fwebhook\u002FLinear, or evaluate which error events are worth alerting on. Covers trigger-event selection, integration choice, dedup against existing alerts, and shipping with the canonical message body shape.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1205,1208,1211,1212],{"name":1206,"slug":1207,"type":13},"Alerting","alerting",{"name":1209,"slug":1210,"type":13},"Debugging","debugging",{"name":1158,"slug":1159,"type":13},{"name":9,"slug":8,"type":13},"2026-06-18T08:24:40.318583",{"slug":1215,"name":1215,"fn":1216,"description":1217,"org":1218,"tags":1219,"stars":20,"repoUrl":21,"updatedAt":1229},"authoring-log-alerts","author log alerts in PostHog","Author useful, low-noise log alerts on services in a PostHog project. Use when the user asks to set up alerts for their logs, suggest alerts they should add, or evaluate whether a service is worth monitoring. Covers service triage, baseline characterisation, threshold drafting, back-testing via simulate, and shipping with a notification destination.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1220,1221,1224,1225,1228],{"name":15,"slug":16,"type":13},{"name":1222,"slug":1223,"type":13},"Monitoring","monitoring",{"name":1158,"slug":1159,"type":13},{"name":1226,"slug":1227,"type":13},"Operations","operations",{"name":9,"slug":8,"type":13},"2026-07-18T05:10:54.430898",{"slug":1231,"name":1231,"fn":1232,"description":1233,"org":1234,"tags":1235,"stars":20,"repoUrl":21,"updatedAt":1246},"building-workflows","build and edit PostHog workflows","Build, edit, test, enable, and monitor PostHog workflows over MCP. Author the action\u002Fedge graph so it runs and opens cleanly in the visual editor, then change drafts surgically with patch operations. Use when asked to build, set up, automate, change, fix, or debug a workflow, campaign, broadcast, drip sequence, or event-triggered automation in the workflows product.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1236,1239,1242,1243],{"name":1237,"slug":1238,"type":13},"Automation","automation",{"name":1240,"slug":1241,"type":13},"MCP","mcp",{"name":9,"slug":8,"type":13},{"name":1244,"slug":1245,"type":13},"Workflow Automation","workflow-automation","2026-07-28T05:34:12.167015",{"slug":1248,"name":1248,"fn":1249,"description":1250,"org":1251,"tags":1252,"stars":20,"repoUrl":21,"updatedAt":1260},"check-posthog-loading","inspect PostHog SDK loading across URLs","Inspect how the PostHog JavaScript SDK is loaded across a list of URLs. Use to confirm consistent installation across pages, find pages missing the snippet, detect mismatched API keys or hosts between pages, and verify the load method (head snippet vs deferred vs array.js).\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1253,1254,1255,1258,1259],{"name":15,"slug":16,"type":13},{"name":1209,"slug":1210,"type":13},{"name":1256,"slug":1257,"type":13},"Frontend","frontend",{"name":1158,"slug":1159,"type":13},{"name":9,"slug":8,"type":13},"2026-05-07T05:56:19.828048",{"slug":991,"name":991,"fn":1262,"description":1263,"org":1264,"tags":1265,"stars":20,"repoUrl":21,"updatedAt":1272},"integrate PostHog endpoints into client applications","Wire a PostHog endpoint into a client app or SDK. Covers fetching the OpenAPI spec, generating a typed client with openapi-generator or @hey-api\u002Fopenapi-ts, sending the right auth header, shaping the variables payload (HogQL code_name vs insight breakdown property), handling rate-limit and materialised-endpoint error responses. Use when the user says \"how do I call my endpoint\", \"generate a client for this\", or \"what auth header do I use\".\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1266,1267,1268,1269],{"name":18,"slug":19,"type":13},{"name":1256,"slug":1257,"type":13},{"name":9,"slug":8,"type":13},{"name":1270,"slug":1271,"type":13},"SDK","sdk","2026-06-08T08:08:34.929454",{"slug":1274,"name":1274,"fn":1275,"description":1276,"org":1277,"tags":1278,"stars":20,"repoUrl":21,"updatedAt":1282},"copying-endpoints-across-projects","copy PostHog endpoints across projects","Copy a PostHog endpoint (a saved HogQL\u002Finsight query exposed as an API route) to another project in the same organization, or duplicate it under a new name in the same project. Use when the user wants to duplicate an endpoint, promote an endpoint from staging to production, replicate an endpoint's query\u002Fvariables\u002Ffreshness config in another workspace, or clone an endpoint to iterate on it. Unlike feature flags and experiments, endpoints have NO native cross-project copy tool — this skill covers the read-then-recreate flow (endpoint-get then endpoint-create), the active-project switching it requires, name-collision checks, and the safe defaults (land unmaterialised in the target, verify with endpoint-run). Does not cover editing endpoint versions (see managing-endpoint-versions) or authoring a brand-new endpoint from scratch (see creating-an-endpoint).\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1279,1280,1281],{"name":18,"slug":19,"type":13},{"name":1226,"slug":1227,"type":13},{"name":9,"slug":8,"type":13},"2026-07-15T05:29:58.442727",{"slug":1284,"name":1284,"fn":1285,"description":1286,"org":1287,"tags":1288,"stars":20,"repoUrl":21,"updatedAt":1300},"creating-ai-subscription","schedule recurring AI-generated PostHog reports","Create a recurring AI-generated PostHog report — schedule a free-text prompt to run on a cron, with the LLM-synthesized markdown delivered to email or Slack on each tick. Use when the user wants a recurring AI summary of X on any cadence (daily, weekly, monthly, yearly) rather than a one-off report. (To attach an AI summary to an existing insight\u002Fdashboard subscription instead of a free-text prompt, see `managing-subscriptions` and its `summary_enabled` option.)\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1289,1290,1293,1294,1297],{"name":1237,"slug":1238,"type":13},{"name":1291,"slug":1292,"type":13},"Email","email",{"name":9,"slug":8,"type":13},{"name":1295,"slug":1296,"type":13},"Reporting","reporting",{"name":1298,"slug":1299,"type":13},"Slack","slack","2026-06-09T07:32:27.935712",{"slug":4,"name":4,"fn":5,"description":6,"org":1302,"tags":1303,"stars":20,"repoUrl":21,"updatedAt":22},{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1304,1305,1306],{"name":15,"slug":16,"type":13},{"name":18,"slug":19,"type":13},{"name":9,"slug":8,"type":13},231,{"items":1309,"total":1359},[1310,1317,1323,1330,1337,1344,1352],{"slug":1148,"name":1148,"fn":1149,"description":1150,"org":1311,"tags":1312,"stars":20,"repoUrl":21,"updatedAt":1161},{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1313,1314,1315,1316],{"name":15,"slug":16,"type":13},{"name":1155,"slug":1156,"type":13},{"name":1158,"slug":1159,"type":13},{"name":9,"slug":8,"type":13},{"slug":1163,"name":1163,"fn":1164,"description":1165,"org":1318,"tags":1319,"stars":20,"repoUrl":21,"updatedAt":1173},{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1320,1321,1322],{"name":15,"slug":16,"type":13},{"name":1170,"slug":1171,"type":13},{"name":9,"slug":8,"type":13},{"slug":1175,"name":1175,"fn":1176,"description":1177,"org":1324,"tags":1325,"stars":20,"repoUrl":21,"updatedAt":1185},{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1326,1327,1328,1329],{"name":1170,"slug":1171,"type":13},{"name":1182,"slug":29,"type":13},{"name":1158,"slug":1159,"type":13},{"name":9,"slug":8,"type":13},{"slug":1187,"name":1187,"fn":1188,"description":1189,"org":1331,"tags":1332,"stars":20,"repoUrl":21,"updatedAt":1198},{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1333,1334,1335,1336],{"name":1170,"slug":1171,"type":13},{"name":1182,"slug":29,"type":13},{"name":1195,"slug":1196,"type":13},{"name":9,"slug":8,"type":13},{"slug":1200,"name":1200,"fn":1201,"description":1202,"org":1338,"tags":1339,"stars":20,"repoUrl":21,"updatedAt":1213},{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1340,1341,1342,1343],{"name":1206,"slug":1207,"type":13},{"name":1209,"slug":1210,"type":13},{"name":1158,"slug":1159,"type":13},{"name":9,"slug":8,"type":13},{"slug":1215,"name":1215,"fn":1216,"description":1217,"org":1345,"tags":1346,"stars":20,"repoUrl":21,"updatedAt":1229},{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1347,1348,1349,1350,1351],{"name":15,"slug":16,"type":13},{"name":1222,"slug":1223,"type":13},{"name":1158,"slug":1159,"type":13},{"name":1226,"slug":1227,"type":13},{"name":9,"slug":8,"type":13},{"slug":1231,"name":1231,"fn":1232,"description":1233,"org":1353,"tags":1354,"stars":20,"repoUrl":21,"updatedAt":1246},{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1355,1356,1357,1358],{"name":1237,"slug":1238,"type":13},{"name":1240,"slug":1241,"type":13},{"name":9,"slug":8,"type":13},{"name":1244,"slug":1245,"type":13},61]