Last updated:

Which features are available in this library?
  • Event capture
  • Autocapture
  • User identification
  • Session recording
  • Feature flags
  • Group analytics

If you're working with Node.js, the official posthog-node library is the simple way to integrate your software with PostHog. This library uses an internal queue to make calls fast and non-blocking. It also batches requests and flushes asynchronously, making it perfect to use in any part of your web app or other server-side application that needs performance. And in addition to event capture, feature flags are supported as well.


Run either npm or yarn in terminal to add it to your project:

npm install posthog-node --save
# or
yarn add posthog-node

In your app, set your API key before making any calls.

import { PostHog } from 'posthog-node'
const client = new PostHog(
{ host: '<ph_instance_address>' } // You can omit this line if using PostHog Cloud
// On program exit, call shutdown to stop pending pollers and flush any remaining events
await client.shutdownAsync()

You can find your key in the 'Project Settings' page in PostHog.

Note: As a rule of thumb, we do not recommend hardcoding API keys. Setting it as an environment variable would be best.


VariableDescriptionDefault value
hostYour PostHog host
flushAtAfter how many capture calls we should flush the queue (in one batch)20
flushIntervalAfter how many ms we should flush the queue10000
personalApiKeyAn optional personal API key for evaluating feature flags locallynull
featureFlagsPollingIntervalInterval in milliseconds specifying how often feature flags should be fetched from the PostHog API300000
requestTimeoutTimeout in milliseconds for any calls10000
maxCacheSizeMaximum size of cache that deduplicates $feature_flag_called calls per user.50000
disableGeoipWhen true, disables automatic GeoIP resolution for events and feature flags.true

Note: When using PostHog in an AWS Lambda function or a similar serverless function environment, make sure you set flushAt to 1 and flushInterval to 0. Also, remember to always call await posthog.shutdownAsync() at the end to flush and send all pending events.

Making calls


Capture allows you to capture anything a user does within your system, which you can later use in PostHog to find patterns in usage, work out which features to improve or where people are giving up.

A capture call requires:

  • distinct id which uniquely identifies your user
  • event name to identify the event
  • We recommend naming events with "[noun][verb]", such as movie played or movie updated, in order to easily identify what your events mean later on (we know this from experience).

Optionally you can submit:

For example:

distinctId: 'distinct id',
event: 'movie played',
properties: {
movieId: '123',
category: 'romcom',

Setting user properties via an event

To set properties on your users via an event, you can leverage the event properties $set and $set_once.

distinctId: 'distinct id',
event: 'movie played',
properties: {
$set: { userProperty: 'value' },

When capturing an event, you can pass a property called $set as an event property, and specify its value to be an object with properties to be set on the user that will be associated with the user who triggered the event.

distinctId: 'distinct id',
event: 'movie played',
properties: {
$set_once: { userProperty: 'value' },

$set_once works just like $set, except that it will only set the property if the user doesn't already have that property set.


We highly recommend reading our section on Identifying users to better understand how to correctly use this method.

Identify lets you add metadata to your users so you can easily identify who they are in PostHog, as well as do things like segment users by these properties.

An identify call requires:

  • distinctId – a distinct ID belonging to the user
  • properties – a user properties object

For example:

distinctId: 'user:123',
properties: {
email: '',
proUser: false,

The most obvious place to make this call is whenever a user signs up, or when they update their information.


To connect whatever a user does before they sign up or log in with what they do after you need to make an alias call. This will allow you to answer questions like "Which marketing channels leads to users churning after a month?" or "What do users do on our website before signing up?"

In a purely back-end implementation, this means whenever an anonymous user does something, you'll want to send a session ID with the capture call. Then, when that users signs up, you want to do an alias call with the session ID and the newly created user ID.

The same concept applies for when a user logs in.

If you're using PostHog in the front-end and back-end, doing the identify call in the frontend will be enough.

An alias call requires:

  • distinctId – the user id
  • alias – the anonymous session distinct ID

For example:

distinctId: 'user:123',
alias: 'session:12345',

Sending page views

If you're aiming for a full back-end implementation of PostHog, you can send pageviews from your backend, like so:

distinctId: 'distinct id',
event: '$pageview',
properties: {
$current_url: '',

Feature flags

PostHog's feature flags enable you to safely deploy and roll back new features.

When using them with one of libraries, you should check if a feature flag is enabled and use the result to toggle functionality on and off in you application.

How to check if a flag is enabled

Note: Whenever we face an error computing the flag, the library returns undefined, instead of true, false, or a string variant value.

// isFeatureEnabled(key: string, distinctId: string, options: {}): Promise<boolean | undefined>
const isMyFlagEnabledForUser = await client.isFeatureEnabled('flag-key', 'user distinct id')
if (isMyFlagEnabledForUser) {
// Do something differently for this user

Disable feature flag events

By default, calling isFeatureEnabled() or getFeatureFlag() sends a $feature_flag_called event so you can analyze flag usage. You can disable this by passing the sendFeatureFlagEvents property:

const isMyFlagEnabledForUser = await client.isFeatureEnabled('flag-key', 'user distinct id', { sendFeatureFlagEvents: false })

Get a flag value

If you're using multivariate feature flags, you can also get the value of the flag, as well as whether or not it is enabled.

Note: Whenever we face an error computing the flag, the library returns None, instead of true or false or a string variant value.

// getFeatureFlag(key: string, distinctId: string, options: {}): Promise<string | boolean | undefined>
const flagValue = await client.getFeatureFlag('flag-key', 'user distinct id')

Overriding server properties

Sometimes, you might want to evaluate feature flags using properties that haven't been ingested yet, or were set incorrectly earlier. You can do so by setting properties the flag depends on with these calls.

For example, if the beta-feature depends on the is_authorized property, and you know the value of the property, you can tell PostHog to use this property, like so:

// getFeatureFlag(
// key: string,
// distinctId: string,
// options?: {
// groups?: Record<string, string>
// personProperties?: Record<string, string>
// groupProperties?: Record<string, Record<string, string>>
// onlyEvaluateLocally?: boolean
// sendFeatureFlagEvents?: boolean
// }
// ): Promise<string | boolean | undefined>
const flagValue = await client.getFeatureFlag('flag-key', 'user distinct id', {
personProperties: { is_authorized: true },

The same holds for groups. If you have a group named organisation, you can add properties like so:

const flagValue = await client.getFeatureFlag('flag-key', 'user distinct id', {groups:{'organisation': 'google'}, groupProperties:{'organisation': {'is_authorized': True}})

Default overridden properties

Before posthog-node v3.0, we added GeoIP properties to all incoming events by default. We also used these properties for feature flag evaluation, based on the IP address of the request. This isn't ideal since they are created based on your server IP address, rather than the user's, leading to incorrect location resolution.

As of posthog-node v3.0, the default now is to disregard the server IP, not add the GeoIP properties, and not use the values for feature flag evaluations.

You can go back to previous behaviour by setting disableGeoip to false in your initialization:

const posthog = new PostHog(PH_API_KEY, {
host: PH_HOST,
disableGeoip: false

The list of properties that this overrides:

  1. $geoip_city_name
  2. $geoip_country_name
  3. $geoip_country_code
  4. $geoip_continent_name
  5. $geoip_continent_code
  6. $geoip_postal_code
  7. $geoip_time_zone

You can also explicitly chose to override / not override properties for a single capture or feature flag request like so:

const flagValue = await client.getFeatureFlag('flag-key', 'user distinct id', {
personProperties: { is_authorized: true },
disableGeoip: `true|false`
distinctId: distinctId,
event: 'test-event',
properties: { foo: 'bar' },
disableGeoip: `true|false`,

Getting all flag values

You can also get all known flag values as well. This is useful when you want to seed a frontend client with initial known flags. Like all methods above, this also takes optional person and group properties, if known.

await client.getAllFlags('distinct id', { groups: {}, personProperties: { is_authorized: True }, groupProperties: {} })
// returns dict of flag key and value pairs.

Feature Flag Payloads

Payloads allow you to retrieve a value that is associated with the matched flag. The value can be a string, boolean, number, dictionary, or array. This allows for custom configurations based on values defined in the posthog app.

This was introduced in PostHog Node v2.3.0

Note: getFeatureFlag does not need to be called prior to getFeatureFlagPayload. getFeatureFlagPayload will implicitly perform getFeatureFlag to determine the matching flag and return the corresponding payload.

// getFeatureFlagPayload(key: string, distinctId: string, matchValue?: string | boolean, options: {}): Promise<JsonType | undefined>
const flagPayload = await client.getFeatureFlagPayload('flag-key', 'user distinct id')

Local Evaluation

Note: To enable local evaluation of feature flags you must also set a personal_api_key when configuring the integration, as described in the Installation section.

Note: This feature requires version 2.0 of the library, which in turn requires a minimum PostHog version of 1.38

All feature flag evaluation requires an API request to your PostHog servers to get a response. However, where latency matters, you can evaluate flags locally. This is much faster, and requires two things to work:

  1. The library must be initialised with a personal API key
  2. You must know all person or group properties the flag depends on.

Then, the flag can be evaluated locally. The method signature looks exactly like above.

await client.getFeatureFlag('beta-feature', 'distinct id', { personProperties: { is_authorized: True } })
// returns string or None

Note: New feature flag definitions are polled every 30 seconds by default, which means there will be up to a 30 second delay between you changing the flag definition, and it reflecting on your servers. You can change this default on the client by setting featureFlagsPollingInterval during client initialisation.

This works for getAllFlags as well. It evaluates all flags locally if possible. If even one flag isn't locally evaluable, it falls back to decide.

await client.getAllFlags('distinct id', { groups: {}, personProperties: { is_authorized: True }, groupProperties: {} })
// returns dict of flag key and value pairs.

Restricting evaluation to local only

Sometimes, performance might matter to you so much that you never want an HTTP request roundtrip delay when computing flags. In this case, you can set the only_evaluate_locally parameter to true, which tries to compute flags only with the properties it has. If it fails to compute a flag, it returns None, instead of going to PostHog's servers to get the value.

Cohort expansion

To support feature flags that depend on cohorts locally as well, we translate the cohort definition into person properties, so that the person properties you set can be used to evaluate cohorts as well.

However, there are a few constraints here and we don't support doing this for arbitrary cohorts. Cohorts won't be evaluated locally if:

  1. They have non-person properties
  2. There's more than one cohort in the feature flag definition.
  3. The cohort in the feature flag is in the same group as another condition.
  4. The cohort has nested AND-OR filters. Only simple cohorts that have a top level OR group, and inner level ANDs will be evaluated locally.

Note that this restriction is for local evaluation only. If you're hitting PostHog's servers, all of these cohorts will be evaluated as expected. Further, posthog-node v2.6.0 onwards, and posthog-python v2.4.0 onwards do not face this issue and can evaluate all cohorts locally.

Reloading feature flags

When initializing PostHog, you can configure the interval at which feature flags are polled (fetched from the server). However, if you need to force a reload, you can use reloadFeatureFlags:

await client.reloadFeatureFlags()
// Do something with feature flags here

Group analytics

Group analytics allows you to associate an event with a group (e.g. teams, organizations, etc.). Read the Group Analytics guide for more information.

Note: This is a paid feature and is not available on the open-source or free cloud plan. Learn more here.

  • Capture an event and associate it with a group
event: 'some event',
distinctId: '[distinct id]',
groups: { company: '42dlsfj23f' },
  • Update properties on a group
groupType: 'company',
groupKey: '42dlsfj23f',
properties: {
name: 'Awesome Inc',
employees: 11,
// optional distinct ID to associate event with an existing person
distinctId: 'xyz'


You should call shutdown on your program's exit to exit cleanly:

// Stop pending pollers and flush any remaining events
// or
await client.shutdownAsync()

Debugging and exceptions

If you are experiencing issues with the SDK it could be a number of things from an incorrectly configured API key, to some other network related issues.

The SDK does not throw errors for things happening in the background to ensure it doesn't affect your process. You can however hook into the errors to get more information:

client.on("error", (err) => {
// Whatever handling you want
console.error("PostHog had an error!", err)

Or you can enable debugging to get verbose logs about all the inner workings of the SDK.


Using in a short-lived process like AWS Lambda

PostHogs's client SDKs are all designed to queue and batch requests in the background to optimise API calls and network time. For lambda environments (or also when shutting down a standard Node.js app) we provide a method .shutdownAsync which can be awaited and ensures the queued events are all flushed to the API.

For example:

export const handler() {
distinctId: 'distinct id',
event: 'thing happened'
distinctId: 'distinct id',
event: 'other thing happened'
// So far 2 events are queued but not sent
// Calling shutdown, flushed the queue but batched into 1 API call for maximum efficiency
await posthog.shutdownAsync()

Upgrading from V1 to V2

V2.x.x of the Node.js library is completely rewritten in Typescript and is based on a new JS core shared with other JavaScript based libraries with the goal of ensuring new features and fixes reach the different libraries at the same pace.

With the release of V2, the API was kept mostly the same but with some small changes and deprecations:

  1. The minimum PostHog version requirement is 1.38
  2. The callback parameter passed as an optional last argument to most of the methods is no longer supported
  3. The method signature for isFeatureEnabled and getFeatureFlag is slightly modified. See the above documentation for each method for more details.
  4. For specific changes, see the CHANGELOG


Was this page useful?

Next article


This is an optional library you can install if you're working with PHP. It uses an internal queue to make calls fast and non-blocking. It also batches requests and flushes asynchronously, making it perfect to use in any part of your web app or other server-side application that needs performance. Installation Add the following to composer.json: And then install the dependencies with the command: php composer.phar install In your app, set your API key before making any calls. Note: As a general…

Read next article