Generated banner for Instrument Integration
Generated logo for Instrument Integration

Instrument Integration

PostHogOfficialCreated by PostHog

  • Skill
  • Tool integration
  • Data and AI
  • MIT
  • Low risk

From the author

Add PostHog SDK integration to your application. Use when setting up PostHog for the first time or reviewing PRs that need PostHog initialization. Covers SDK installation, provider setup, and basic configuration for any framework.
— the description by PostHog

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a structured, multi-step procedure for integrating the PostHog SDK into a wide range of web, mobile, and backend frameworks. It handles the detection of the project environment, installation of the appropriate SDK, initialization, user identification, and secure configuration of environment variables. The skill emphasizes following framework-specific patterns and maintaining an analytics contract, ensuring that PostHog is implemented consistently without disrupting existing application logic.

What it does

  • Detects the project's framework, language, and package manager.
  • Installs the correct PostHog SDK for the identified platform.
  • Configures PostHog initialization and provider setup based on framework-specific references.
  • Implements user identification logic for login and signup events.
  • Manages environment variables for project tokens and host URLs securely.
  • Verifies the integration and performs minimal cleanup.

When to use it

  • When setting up PostHog in a project for the first time.
  • When reviewing pull requests that require PostHog initialization.
  • When adding analytics to a new application across supported frameworks.
  • When migrating or updating PostHog configurations in an existing codebase.

Advantages

  • Ensures consistent implementation across diverse technology stacks.
  • Prevents hardcoding of sensitive project tokens and host URLs.
  • Follows established framework-specific best practices and patterns.
  • Minimizes the risk of breaking application boot or build processes.
  • Automates the repetitive aspects of SDK setup and environment configuration.

Usage examples

“Set up PostHog in my Next.js project.”
The agent will detect the Next.js environment, install the PostHog SDK, configure the necessary provider, and set up environment variables in .env.local.
“Integrate PostHog into this Android app.”
The agent will identify the Android/Kotlin structure, initialize PostHog in the Application class, and guide the setup of local.properties for configuration.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/posthog/instrument-integration/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip instrument-integration.zip -d .agents/skills

Documentation by PostHog

Add PostHog SDK integration

Use this skill to add the PostHog SDK to an application. Use it when setting up PostHog for the first time, or reviewing PRs that need PostHog initialization. Covers SDK installation, provider setup, and basic configuration. Supports any framework or language.

Supported frameworks and languages: Next.js, React, React Router, Vue, Nuxt, TanStack Start, SvelteKit, Astro, Angular, Django, Flask, FastAPI, Laravel, PHP, Ruby on Rails, Go, Elixir, Android, iOS, Swift, Flutter, React Native, Expo, Node.js, and vanilla JavaScript.

Instructions

Follow these steps IN ORDER:

STEP 1: Analyze the codebase and detect the platform.

Look for dependency files (package.json, pubspec.yaml, Podfile, Package.swift, requirements.txt, Gemfile, composer.json, go.mod, mix.exs, etc.) to determine the framework and language.

Look for lockfiles (pnpm-lock.yaml, package-lock.json, yarn.lock, bun.lockb, go.sum, pubspec.lock, Podfile.lock, Package.resolved, mix.lock) to determine the package manager.

  • Check for existing PostHog setup. If PostHog is already installed and initialized, do not modify its code. Inform the user and skip to verification.

STEP 2: Research integration. 2.1. Find the reference file below that matches the detected framework — it is the source of truth for SDK initialization, provider setup, and configuration patterns. Read it now. 2.2. If no reference matches, fall back to your general knowledge and web search. Use posthog.com/docs as the primary search source.

STEP 3: Install the PostHog SDK.

  • Add the PostHog SDK package for the detected platform. Do not manually edit package.json — use the package manager's install command.

STEP 4: Initialize PostHog.

  • Follow the framework reference for where and how to initialize. This varies significantly by framework (e.g., instrumentation-client.ts for Next.js 15.3+, AppConfig.ready() for Django, create_app() for Flask).

  • Set up the PostHog provider/wrapper component if the framework requires one.

STEP 5: Identify users.

  • Add PostHog identify() calls on the client side during login and signup events.

  • If both frontend and backend exist, pass the client-side session and distinct ID using X-POSTHOG-DISTINCT-ID and X-POSTHOG-SESSION-ID headers to the server-side code.

STEP 6: Set up environment variables.

  • Check if the project already has PostHog environment variables configured (e.g. in .env, .env.local, or framework-specific env files). If valid values already exist, skip this step.

  • If the PostHog project token is missing, use the PostHog MCP server's projects-get tool to retrieve the project's api_token. If multiple projects are returned, ask the user which project to use. If the MCP server is not connected or not authenticated, ask the user for their PostHog project token instead.

  • For the PostHog host URL: check the projects-get MCP response for a region field — US maps to https://us.i.posthog.com, EU maps to https://eu.i.posthog.com. If the region is not available from the MCP response or from existing project configuration, ask the user: "Are you on PostHog US Cloud or EU Cloud?" Do not assume US Cloud.

  • Write these values to the appropriate env file (e.g. .env.local for Next.js, .env for others) using the framework's naming convention.

  • Reference these environment variables in code instead of hardcoding them.

STEP 7: Verify and clean up.

  • Check the project for errors. Look for type checking or build scripts in package.json.

  • Ensure any components created were actually used.

  • Run any linter or prettier-like scripts found in the package.json, but ONLY on the files you have edited or created during this session. Never run formatting or linting across the entire project's codebase.

Reference files

  • references/EXAMPLE-next-app-router.md - next-app-router example project code

  • references/EXAMPLE-next-pages-router.md - next-pages-router example project code

  • references/EXAMPLE-react-react-router-6.md - react-react-router-6 example project code

  • references/EXAMPLE-react-react-router-7-framework.md - react-react-router-7-framework example project code

  • references/EXAMPLE-react-react-router-7-data.md - react-react-router-7-data example project code

  • references/EXAMPLE-react-react-router-7-declarative.md - react-react-router-7-declarative example project code

  • references/EXAMPLE-react-vite.md - react-vite example project code

  • references/EXAMPLE-nuxt-3-6.md - nuxt-3-6 example project code

  • references/EXAMPLE-nuxt-4.md - nuxt-4 example project code

  • references/EXAMPLE-vue-3.md - vue-3 example project code

  • references/EXAMPLE-react-tanstack-router-file-based.md - react-tanstack-router-file-based example project code

  • references/EXAMPLE-react-tanstack-router-code-based.md - react-tanstack-router-code-based example project code

  • references/EXAMPLE-tanstack-start.md - tanstack-start example project code

  • references/EXAMPLE-sveltekit.md - sveltekit example project code

  • references/EXAMPLE-astro-static.md - astro-static example project code

  • references/EXAMPLE-astro-view-transitions.md - astro-view-transitions example project code

  • references/EXAMPLE-astro-ssr.md - astro-ssr example project code

  • references/EXAMPLE-astro-hybrid.md - astro-hybrid example project code

  • references/EXAMPLE-angular.md - angular example project code

  • references/EXAMPLE-javascript-node.md - javascript-node example project code

  • references/EXAMPLE-javascript-web.md - javascript-web example project code

  • references/EXAMPLE-django.md - django example project code

  • references/EXAMPLE-flask.md - flask example project code

  • references/EXAMPLE-fastapi.md - fastapi example project code

  • references/EXAMPLE-python.md - python example project code

  • references/EXAMPLE-laravel.md - laravel example project code

  • references/EXAMPLE-php.md - php example project code

  • references/EXAMPLE-ruby-on-rails.md - ruby-on-rails example project code

  • references/EXAMPLE-ruby.md - ruby example project code

  • references/EXAMPLE-android.md - android example project code

  • references/EXAMPLE-swift.md - swift example project code

  • references/EXAMPLE-react-native.md - react-native example project code

  • references/EXAMPLE-expo.md - expo example project code

  • references/next-js.md - Next.js

  • references/react.md - React

  • references/react-router-v6.md - React router v6

  • references/react-router-v7-framework-mode.md - React router v7 framework mode (remix v3)

  • references/react-router-v7-data-mode.md - React router v7 data mode

  • references/react-router-v7-declarative-mode.md - React router v7 declarative mode

  • references/nuxt-js-3-6.md - Nuxt.js (v3.0 to v3.6)

  • references/nuxt-js.md - Nuxt.js

  • references/vue-js.md - Vue.js

  • references/tanstack-start.md - Tanstack start

  • references/svelte.md - Svelte

  • references/astro.md - Astro

  • references/angular.md - Angular

  • references/js.md - JavaScript web

  • references/posthog-js.md - PostHog JavaScript web SDK

  • references/node.md - Node.js

  • references/posthog-node.md - PostHog Node.js SDK

  • references/django.md - Django

  • references/flask.md - Flask

  • references/python.md - Python

  • references/posthog-python.md - PostHog python SDK

  • references/dotnet.md - .net

  • references/elixir.md - Elixir

  • references/go.md - Go

  • references/laravel.md - Laravel

  • references/php.md - Php

  • references/ruby-on-rails.md - Ruby on rails

  • references/ruby.md - Ruby

  • references/android.md - Android

  • references/ios.md - Ios

  • references/usage.md - Ios SDK usage

  • references/configuration.md - Ios SDK configuration

  • references/flutter.md - Flutter

  • references/react-native.md - React native

  • references/identify-users.md - Identify users

  • references/COMMANDMENTS.md - Framework-specific rules the integration must follow

Each framework reference contains SDK-specific installation, initialization, and usage patterns. Find the one matching the user's stack.

Key principles

  • Environment variables: Always use environment variables for PostHog keys. Never hardcode them.

  • Minimal changes: Add PostHog code alongside existing integrations. Don't replace or restructure existing code.

  • Match the example: Your implementation should follow the example project's patterns as closely as possible.

  • Analytics contract: Treat event names, property names, and feature flag keys as part of an analytics contract. Reuse existing names and patterns found in the project. When introducing new ones, make them clear, descriptive, and consistent with existing conventions.

Files

references/configuration.md

AI agents: this is one page from PostHog's docs. Full index of Markdown docs for LLMs: https://posthog.com/llms.txt

iOS SDK configuration

Canonical URL: https://posthog.com/docs/libraries/ios/configuration

Cloud region: This page uses US Cloud hosts. For an EU Cloud project, use https://eu.i.posthog.com instead of https://us.i.posthog.com (ingestion host).

On this page

  • Autocapture configuration

  • Tracing headers

  • Flush configuration

  • Amending, dropping or sampling events

  • Setting up app groups

  • Method swizzling

  • Custom keyboard extensions

  • All configuration options

Autocapture configuration

You can enable or disable autocapture through the PostHogConfig object.

Tracing headers

Use tracingHeaders to connect iOS network requests to backend events, errors, and LLM traces captured by a server-side PostHog SDK:

let configuration = PostHogConfig(projectToken: "<ph_project_token>", host: "https://us.i.posthog.com")
configuration.tracingHeaders = ["api.example.com"]
PostHogSDK.shared.setup(configuration)

Hostnames are matched exactly and should not include protocols, paths, ports, or wildcard subdomains. Matching URLSession requests include X-POSTHOG-DISTINCT-ID and X-POSTHOG-SESSION-ID when those values are available.

Tracing headers require method swizzling, so configuration.enableSwizzling must remain true.

Flush configuration

The iOS SDK 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 mobile app.

You can configure how many events queue before flushing with flushAt. Setting this to 1 will send events immediately and will use more battery. The default is 20.

You can also configure the flush interval with flushIntervalSeconds (default 30), after which queued events are sent regardless of how many have been gathered:

configuration.flushAt = 1
configuration.flushIntervalSeconds = 30

You can also manually flush the queue to start sending events immediately instead of waiting for the next batch:

PostHogSDK.shared.capture("logged_out")
PostHogSDK.shared.flush()

Flushing is best-effort and asynchronous – it starts sending queued events in the background but doesn't wait for the request to finish, so it isn't a delivery guarantee.

Amending, dropping or sampling events

Since version 3.28.0, you can provide a BeforeSendBlock function when initializing the SDK to amend, drop or sample events before they are sent to PostHog.

⚠️ Note: This replaces the deprecated propertiesSanitizer option and provides more flexibility in modifying events. You can achieve the same functionality as propertiesSanitizer by using a BeforeSendBlock that mutates the event's properties in place.

🚨 Warning: Amending and sampling events is advanced functionality that requires careful implementation. Core PostHog features may require 100% of unmodified events to function properly. We recommend only modifying or sampling your own custom events if possible, and preserving all PostHog internal events in their original form.

Redacting information in events

BeforeSendBlock gives you one place to edit or redact information before it is sent to PostHog. For example:

Redact URLs in event properties

let config = PostHogConfig(projectToken: "<ph_project_token>", host: "<ph_api_client_host>")

config.setBeforeSend { event in
    // Redact URLs
    if let url = event.properties["url"] as? String {
        event.properties["url"] = url.map { _ in "*" }.joined()
    }
    return event
}

Redact sensitive information from event properties

let config = PostHogConfig(projectToken: "<ph_project_token>", host: "<ph_api_client_host>")

config.setBeforeSend { event in
    // Redact sensitive information
    if let email = event.properties["email"] as? String {
        event.properties["email"] = email.map { _ in "*" }.joined()
    }

    return event
}

Drop events by event name

let config = PostHogConfig(projectToken: "<ph_project_token>", host: "<ph_api_client_host>")

config.setBeforeSend { event in
    // Drop all events named "Stale Event"
    if event.event == "Stale Event" {
        return nil
    }
    return event
}

Filter autocaptured screen views

You can stop specific screens from being autocaptured by filtering them in your before-send hook. Return null for any $screen event whose $screen_name matches a screen you don't want to track, and it's dropped before being sent – keeping unwanted screen views out of your event log.

Because it's just a function, you can filter however you like – an ignorelist (drop the screens you name), an allowlist (invert the check to capture only the screens you name), or any custom rule such as a name prefix, a regex, or a check against the event's properties.

let config = PostHogConfig(projectToken: "<ph_project_token>", host: "<ph_api_client_host>")

let ignoredScreens: Set<String> = ["Splash", "Debug"]

config.setBeforeSend { event in
    if event.event == "$screen",
       let screenName = event.properties["$screen_name"] as? String,
       ignoredScreens.contains(screenName) {
        return nil
    }
    return event
}
Sampling events

Sampling lets you choose to send only a percentage of events to PostHog. It is a good way to control your costs without having to completely turn off features of the SDK.

Sample events by event name

let config = PostHogConfig(projectToken: "<ph_project_token>", host: "<ph_api_client_host>")

config.setBeforeSend { event in
    // Sample 10% of Sampled Event events
    if event.event == "Sampled Event" {
        if Double.random(in: 0...1) < 0.1 {
            event.properties["$sample_type"] = ["sampleByEvent"]
            event.properties["$sample_threshold"] = 0.1
            event.properties["$sampled_events"] = ["Sampled Event"]
            return event
        }
        return nil
    }
    return event
}
Chaining multiple BeforeSendBlocks

You can provide an array of BeforeSendBlock functions to be called one after the other:

let config = PostHogConfig(projectToken: "<ph_project_token>", host: "<ph_api_client_host>")

config.setBeforeSend(
    // First block: Drop all events named "Stale Event"
    { event in
        if event.event == "Stale Event" {
            return nil
        }
        return event
    },
    // Second block: Redact sensitive information
    { event in
        if let email = event.properties["email"] as? String {
            event.properties["email"] = email.map { _ in "*" }.joined()
        }
        return event
    }
)

Note: When chaining beforeSend blocks, order is important. The first block is executed first and the mutated event is passed along to the second block, and so on. If at any point in the chain the event is dropped, any subsequent blocks will not be executed.

Setting up app groups

  1. Configure App Groups: Set up an App Group in Xcode for your main app and extension targets

  2. Configure PostHog: Use the same App Group identifier in all targets:

let config = PostHogConfig(projectToken: "<ph_project_token>", host: "<ph_api_client_host>")
config.appGroupIdentifier = "group.com.yourcompany.yourapp"
PostHogSDK.shared.setup(config)

Method swizzling

Method swizzling is a technique that enables the SDK to intercept and modify method calls at runtime to provide advanced features like screen view tracking, element interactions, session replay, surveys, and more.

Method swizzling is enabled by default, but can be disabled by setting the relevant config option to false in the PostHogConfig object:

FeatureDescriptionConfig option
Screen view trackingAutomatically captures when view controllers are presentedconfig.captureScreenViews
Element interactionsAutomatically tracks user interactions with UI elementsconfig.captureElementInteractions
Rage clicksAutomatically captures $rageclick events for rapid repeated taps in the same area (iOS/macCatalyst, UIKit)config.rageClickConfig.enabled
Session replayRecords user sessionsconfig.sessionReplay
SurveysDisplays surveys at appropriate timesconfig.surveys
Advanced metrics trackingProvides more precise session ID calculation and rotation by detecting user activity and idlenessN/A
Disabling all method swizzling

Since version 3.34.0, you can opt out of all swizzling using the enableSwizzling configuration option. When you disable swizzling, the SDK disables the features listed above.

let config = PostHogConfig(projectToken: "<ph_project_token>", host: "<ph_api_client_host>")
config.enableSwizzling = false
PostHogSDK.shared.setup(config)

Note: When method swizzling is disabled, features that depend on it will not work even if they are individually enabled in the config. For example, if you set config.sessionReplay = true and config.enableSwizzling = false, session replay will not be enabled.

Session metrics management

Method swizzling is particularly important for accurate session metrics tracking. With swizzling enabled, the SDK can better detect user activity and idle times to provide a better session rotation.

With swizzling disabled, the SDK only uses application open/backgrounded events to detect user activity, which can lead to a sub-optimal session calculation.

Custom keyboard extensions

Custom keyboard extensions have stricter security rules than other extension types. To use PostHog in a custom keyboard, the keyboard must have Open Access permission enabled. This permission is required for network requests and write access to shared containers.

Users must explicitly grant Open Access in Settings > General > Keyboard > Keyboards > [Your Keyboard] > Allow Full Access.

All configuration options

The PostHogConfig object contains several other settings you can toggle:

AttributeDescription
flushAt Type: Integer Default: 20 (5 on tvOS)The number of queued events that the posthog client should flush at. Setting this to 1 will not queue any events and will use more battery.
flushIntervalSeconds Type: TimeInterval Default: 30The amount of time to wait before each tick of the flush timer, in seconds. Smaller values will make events delivered in a more real-time manner and also use more battery. A value smaller than 10 seconds will seriously degrade overall performance.
maxQueueSize Type: Integer Default: 1000 (100 on tvOS)The maximum number of items to queue before starting to drop old ones. This should be a value greater than zero, the behavior is undefined otherwise.
maxBatchSize Type: Integer Default: 50Number of maximum events in a batch call.
maxRetries Type: Integer Default: 3Maximum number of consecutive flush attempts before the entire queue is dropped to avoid infinite retries against a permanently-broken backend (e.g. wrong API key, exhausted quota, deterministic 5xx). Increments on every retriable failure including HTTP 413 cap halving; resets on a successful 2xx response.
captureApplicationLifecycleEvents Type: Boolean Default: trueWhether the posthog client should automatically make a capture call for application lifecycle events, such as "Application Installed", "Application Updated" and "Application Opened".
captureScreenViews Type: Boolean Default: trueWhether the posthog client should automatically make a screen call when a view controller is added to a view hierarchy. Because the underlying implementation uses method swizzling, we recommend initializing the posthog client as early as possible (before any screens are displayed), ideally during the Application delegate's applicationDidFinishLaunching method.
enableSwizzling Type: Boolean Default: trueEnable method swizzling for SDK functionality that depends on it. When disabled, functionality that requires swizzling (like autocapture, screen views, session replay, surveys) will not be installed.
captureElementInteractions Type: Boolean Default: false(UIKit only) Whether the posthog client should automatically make a capture call when the user interacts with an element in a screen.
rageClickConfig Type: Object Default: .init()(iOS/macCatalyst, UIKit) Rage click detection configuration. Includes enabled (default true), minimumTapCount (default 3), thresholdPoints (default 30), and timeoutInterval (default 1.0). Works independently of captureElementInteractions. Available in version 3.51.0+.
sendFeatureFlagEvent Type: Boolean Default: trueSend a $feature_flag_called event when a feature flag is used automatically.
preloadFeatureFlags Type: Boolean Default: truePreload feature flags automatically.
evaluationContexts Type: Array of Strings Default: undefinedEvaluation context tags that constrain which feature flags are evaluated. When set, only flags with matching evaluation context tags (or no evaluation context tags) will be returned. See evaluation contexts documentation for more details. Available in version 3.38.0+. The legacy parameter evaluationEnvironments (version 3.33.0+) is also supported for backward compatibility.
debug Type: Boolean Default: falseLogs the SDK messages to the Xcode console.
optOut Type: Boolean Default: falsePrevents capturing any data if enabled.
getAnonymousId Type: Function Default: undefinedHook that allows for modification of the default mechanism for generating anonymous id (which as of now is just random UUID v7).
dataMode Type: Enum Default: .anyControls when queued data is flushed. Use .wifi to flush only on Wi-Fi; .cellular is a legacy value and behaves like .any.
personProfiles Type: Enum Default: .identifiedOnlyDetermines the behavior for processing user profiles.
setDefaultPersonProperties Type: Boolean Default: trueAutomatically set common device and app properties (such as $app_version, $os_name, and $device_type) as person properties for feature flag evaluation. See property overrides for more details.
sessionReplay Type: Boolean Default: falseEnable Recording of Session Replays.
sessionReplayConfig Type: Object Default: .init()Session Replay configuration. See Session Replay installation for more details.
tracingHeaders Type: Array of Strings Default: nilExact hostnames that should receive PostHog tracing headers when the SDK instruments URLSession requests.
errorTrackingConfig Type: Object Default: .init()Error Tracking configuration. See the error tracking docs for more details.
logs Type: Object Default: .init()Structured Logs configuration. See Logs installation for more details.
surveysConfig Type: Object Default: .init()Surveys configuration, including custom survey delegates and display language overrides.
urlSessionConfiguration Type: URLSessionConfiguration Default: .defaultCustom URLSessionConfiguration used by the SDK for PostHog API requests.
appGroupIdentifier Type: String Default: nilThe identifier of the App Group that should be used to store shared analytics data. PostHog will try to get the physical location of the App Group's shared container, otherwise fallback to the default location.
reuseAnonymousId Type: Boolean Default: falseWhether the SDK should reuse the anonymous Id between user changes. When enabled, a single Id will be used for all anonymous users on this device.
surveys Type: Boolean Default: trueEnable Surveys.
setBeforeSend Type: Function Default: undefinedHook that allows for amending, sampling, or dropping events before they are sent to PostHog.
bootstrap Type: PostHogBootstrapConfig Default: nilSeeds identity (distinctId, isIdentifiedId) and feature-flag state (featureFlags, featureFlagPayloads) before the first /flags response. Bootstrapped identity applies to the first session; only enabled flags are served, until the first /flags response replaces them. See SDK bootstrapping.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs an MCP server, Needs Python, Needs Node.js

Security

What our scanner noticed· Low risk

  • Instructions that use the network

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
PostHog
Publisher
PostHog (Official)
Source
PostHog/skills · skills/omnibus/instrument-integration · commit a5d30e7
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by PostHog.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download instrument-integration.zip