Node.js

If you're working with Node.js, the official posthog-node library is the simplest 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.

Installation

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 project API key before making any calls.

import { PostHog } from 'posthog-node'

const client = new PostHog(
    '<ph_project_api_key>',
    { host: '<ph_instance_address>' } 
)

await client.shutdownAsync() 

You can find your project API key and instance address 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 is preferred.

Options

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.

Capturing events

You can send custom events using capture:

client.capture({
    distinctId: 'distinct_id_of_the_user',
    event: 'user signed up"',
})

Tip: We recommend using a '[object][verb]' format for your event names, where '[object]' is the entity that the behavior relates to, and '[verb]' is the behavior itself. For example, project created, user signed up, or invite sent.

Setting event properties

Optionally, you can also include additional information in the event by setting the properties value:

client.capture({
    distinctId: 'distinct_id_of_the_user',
    event: 'user signed up"',
    properties: {
        login_type: 'email',
        is_free_trial: true,
    },
})

Capturing pageviews

If you're aiming for a backend-only implementation of PostHog and won't be capturing events from your frontend, you can send pageviews from your backend like so:

client.capture({
    distinctId: 'distinct_id_of_the_user',
    event: '$pageview',
    properties: {
        $current_url: 'https://example.com',
    },
})

Setting user properties

To set user properties, include the properties you'd like to set when capturing an event:

client.capture({
    distinctId: 'distinct id',
    event: 'movie played',
    properties: {
        $set: { name: 'Max Hedgehog'  },
        $set_once: { initial_url: '/blog' },
    },
})

For more details on the difference between $set and $set_once, see our user properties docs.

Alias

Sometimes, you may want to assign multiple distinct IDs to a single user. This is helpful in scenarios where your primary distinct ID may be inaccessible. For example, if a distinct ID which is typically used on the frontend is not available in certain parts of your backend code. In this case, you can use alias to assign another distinct ID to the same user.

We strongly recommend reading our docs on alias to best understand how to correctly use this method.

Feature flags

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

There are 2 steps to implement feature flags in Node:

Step 1: Evaluate the feature flag value

Boolean feature flags

const isFeatureFlagEnabled = await client.isFeatureEnabled('flag-key', 'distinct_id_of_your_user')
if (isFeatureFlagEnabled) {
    // Your code if the flag is enabled

    // Optional: fetch the payload
    const matchedFlagPayload = await client.getFeatureFlagPayload('flag-key', 'distinct_id_of_your_user')
}

Multivariate feature flags

const enabledVariant = await client.getFeatureFlag('flag-key', 'distinct_id_of_your_user')

if (enabledVariant === 'variant-key') {  // replace 'variant-key' with the key of your variant
    // Do something differently for this user

    // Optional: fetch the payload
    const matchedFlagPayload = await client.getFeatureFlagPayload('flag-key', 'distinct_id_of_your_user')
}

Step 2: Include feature flag information when capturing events

If you want use your feature flag to breakdown or filter events in your insights, you'll need to include feature flag information in those events.

This ensures that the feature flag value is attributed correctly to the event.

Note: this step is only required for events captured using our server-side SDKs or API.

There are two methods you can use to include feature flag information in your events:

Method 1: Include the $feature/feature_flag_name property

In the event properties, include $feature/feature_flag_name: variant_key:

client.capture({
    distinctId: 'distinct_id_of_your_user',
    event: 'event_name',
    properties: {
        '$feature/feature-flag-key': 'variant-key' // replace feature-flag-key with your flag key. Replace 'variant-key' with the key of your variant
    },
})

Method 2: Set sendFeatureFlags to true

The capture() method has an optional argument sendFeatureFlags, which is set to false by default. By setting this to true, feature flag information will automatically be sent with the event.

Note that by doing this, PostHog will make an additional request to fetch feature flag information before capturing the event. So this method is only recommended if you don't mind the extra API call and delay.

client.capture({
    distinctId: 'distinct_id_of_your_user',
    event: 'event_name',
    sendFeatureFlags: true,
})

Fetching all flags for a user

You can fetch all flag values for a single user by calling getAllFlags() or getAllFlagsAndPayloads().

This is useful when you need to fetch multiple flag values and don't want to make multiple requests.

await client.getAllFlags('distinct_id_of_your_user') 
await client.getAllFlagsAndPayloads('distinct_id_of_your_user')

Advanced: Overriding server properties

Sometimes, you may want to evaluate feature flags using person properties, groups, or group properties that haven't been ingested yet, or were set incorrectly earlier.

You can provide properties to evaluate the flag with by using the person properties, groups, and group properties arguments. PostHog will then use these values to evaluate the flag, instead of any properties currently stored on your PostHog server.

For example:

await client.getFeatureFlag(
    'flag-key',
    'distinct_id_of_the_user',
    {
        personProperties: {
            'property_name': 'value'
        },
        groups: {
            "your_group_type": "your_group_id",
            "another_group_type": "your_group_id",
        },
        groupProperties: {
            'your_group_type': {
                'group_property_name': 'value'
            },
            'another_group_type': {
                'group_property_name': 'value'
            } 
        },
    }
)

Local Evaluation

Evaluating feature flags requires making a request to PostHog for each flag. However, you can improve performance by evaluating flags locally. Instead of making a request for each flag, PostHog will periodically request and store feature flag definitions locally, enabling you to evaluate flags without making additional requests.

It is best practice to use local evaluation flags when possible, since this enables you to resolve flags faster and with fewer API calls.

For details on how to implement local evaluation, see our local evaluation guide.

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

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

Experiments (A/B tests)

Since experiments use feature flags, the code for running an experiment is very similar to the feature flags code:

const variant = await client.getFeatureFlag('experiment-feature-flag-key', 'user_distinct_id')

if (variant === 'variant-name') {
    // do something
}

It's also possible to run experiments without using feature flags.

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

client.capture({
    event: 'some event',
    distinctId: '[user distinct id]',
    groups: { company: 'company_id_in_your_db' },
})

• Update properties on a group

client.groupIdentify({
    groupType: 'company',
    groupKey: 'company_id_in_your_db',
    properties: {
        name: 'Awesome Inc',
        employees: 11,
    },
    // optional distinct ID to associate event with an existing person
    distinctId: 'xyz'
})

GeoIP 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 behavior 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 enable or disable GeoIP for a single capture request like so:

client.capture({
  distinctId: distinctId,
  event: 'your-event',
  disableGeoip: `true`,
})

Shutdown

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

// Stop pending pollers and flush any remaining events
client.shutdown()
// 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.

client.debug()

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() {
  client.capture({
    distinctId: 'distinct id',
    event: 'thing happened'
  })

  client.capture({
    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