- Home
- Resources
- Integrations
- PostHog
PostHog n8n integrationAutomate PostHog with n8n.
Product analytics is only as good as the events that reach it. The PostHog n8n integration handles that last hop: 5 operations spread over 4 resources create an event, an alias or an identity, and track a page or a screen. PostHog ships no trigger node, so the workflow starts somewhere else.
Verified Trustpilot reviews · AI, automation & growth agency
What does the PostHog n8n integration cover?
The PostHog node is a writer. It takes an item running through your workflow and turns it into something PostHog can store: an event with a name and properties, an identity, an alias, or a tracked page or screen. Each call needs a distinct ID, the value PostHog uses to tell one user from another. The node is built into n8n, and the credential you create for it is reused by every workflow in the instance.
Start with the case most teams hit first: an event that never existed in the browser. A payment confirmed by a backend job, a contract signed inside a CRM, a support ticket closed by an agent. None of that fires from a page, so nothing lands in PostHog. A workflow that already receives the payload calls event.create, names the event, attaches the distinct ID, and the funnel finally shows the step.
Second case: identity work at the edges of your product. The identity.create operation writes an identity from a distinct ID, and alias.create records an alias name against that same distinct ID. Workflows that read from a spreadsheet or an inbox are a natural fit here, since a batch coming from Google Sheets or an alert routed through Slack often carries the identifier long before the product does.
Third case: page and screen tracking driven from the server. track.page and track.screen each take a Name and a distinct ID, which makes them useful when the view happens somewhere a client-side snippet does not run. Teams already sending the same stream to Segment or Google Analytics can fan out from one workflow instead of wiring three integrations by hand.
Now the honest part. The catalog is 5 operations across 4 resources, and that is the whole surface of the node. Anything else in the PostHog API is reached with the HTTP Request node, which calls any endpoint of the tool while reusing the same credential through predefined authentication. It is not a downgrade, just a different node in the same canvas.
The other thing to plan around: PostHog has no trigger node in n8n. A workflow that concerns it starts with a Schedule Trigger on a fixed interval, with the n8n Webhook node called by another service, or with the trigger of another tool. The public n8n library has a template built exactly that way, 968, which creates a PostHog event when a request hits a webhook URL. If you want the wider picture on the platform before wiring anything, there is the n8n review, and the n8n training for building these workflows yourself.
How do you connect PostHog to n8n?
- 01
Get the API key that matches your endpoints
You need a PostHog account, or PostHog hosted on your own server. The key depends on what the node will reach. For public POST-only endpoints, take a Project API key from your project's General settings. For private endpoints, take a Personal API key from the Personal API Keys section of your user account settings. They are two different keys from two different screens, so grab the one your workflow actually needs.
- 02
Pick the right API URL
The credential asks for an URL, and the correct domain depends on where your project lives. On US Cloud, use
https://us.i.posthog.comfor public POST-only endpoints orhttps://us.posthog.comfor private ones. On EU Cloud, the pair ishttps://eu.i.posthog.comandhttps://eu.posthog.com. On a self-hosted instance, use your own domain. Checking the URL of your PostHog instance confirms which one you are on. - 03
Save the credential once in n8n
Open the Credentials menu in n8n, create the PostHog credential, and fill the URL and API Key fields. A credential is created once and reused by every workflow in the instance, so you do this on day one and never again. Drop a PostHog node on the canvas and the credential shows up in its dropdown, ready to select. Same steps on n8n Cloud and on a self-hosted instance.
What can the PostHog node do?
The PostHog node exposes 5 operations across 4 resources. For each one: the node as you configure it in n8n, the required fields, and our field notes.
Operations index
Alias
1 operationCreate an alias
alias.createWhat you see in n8n
Notes & use cases
Records an alias name against a user you already track by distinct ID. One item in, one alias stored in PostHog.
Key parameters
- Alias: the name of the alias. Required, and it can be typed in the node or pulled from the incoming item with
{{ $json.field }}. - Distinct ID: the user's distinct ID. Also required, and a required field left empty stops the node before the call goes out.
- Timestamp: sits in Additional Fields. Left unset it is automatically set to the current time, which matters when you replay a backlog.
Event
1 operationCreate an event
event.createWhat you see in n8n
Notes & use cases
The workhorse of the node. It sends one named event to PostHog for one user, so a step that happens outside the browser still shows up in your funnels.
Key parameters
- Event: the name of the event, required. This is the label you will look for in PostHog, so keep it stable across runs.
- Distinct ID: the user's distinct ID, required. It usually comes from the previous node, written as
{{ $json.field }}. - Properties: an Additional Fields collection with an Add Property button, one row per property you want carried with the event.
Identity
1 operationCreate an identity
identity.createWhat you see in n8n
Notes & use cases
Only one field is truly needed here: the identity's distinct ID. That makes it the cheapest call of the five, and a good first node when a workflow discovers a person before the product does.
Key parameters
- Distinct ID: the identity's distinct ID, required and the only mandatory field of the operation.
- Properties: in Additional Fields, with the same Add Property pattern used elsewhere in the node.
- Timestamp: also optional. Unset means the current time is used automatically.
Track
2 operationsTrack a page
track.pageWhat you see in n8n
Notes & use cases
Registers a page view in PostHog from the workflow instead of from a browser. Useful whenever the page is served somewhere a client-side snippet never runs.
Key parameters
- Name: required, the name of the page being tracked.
- Distinct ID: the user's distinct ID, required, so the view is attached to someone rather than floating on its own.
- Properties: available in Additional Fields through Add Property, one row per property.
Track a screen
track.screenWhat you see in n8n
Notes & use cases
Same idea, different surface: this one records a screen rather than a page, and takes the screen name plus the person it belongs to.
Key parameters
- Name: required, the name of the screen being tracked.
- Distinct ID: the user's distinct ID, required.
- Timestamp: optional, in Additional Fields. When it is not set, the current time is used, so pass a value when the screen was reached earlier than the workflow run.
Need help automating PostHog with n8n?
A person reads every message.

