Integrations

Kite integrations connect the customer state computed by Kite to the tools your team already uses. GitHub makes configuration delivery traceable. PostHog adds lifecycle, health, and segment context to customer profiles.

Manage both integrations from Dashboard > Integrations. Only organization owners and admins can connect or configure them.

GitHub

The GitHub integration establishes a verifiable link between a Kite configuration version and the GitHub Actions run that deployed it. This gives every release a source trail without asking teams to copy commit or workflow details manually.

How deployment provenance works

Install the Kite GitHub App on a personal account or organization.
Choose whether the app can access all repositories or only selected repositories.
Run kite deploy from GitHub Actions.
The CLI detects the GitHub Actions environment and attaches available provenance to the new configuration version.
Kite displays that source alongside the version in the configuration history.

When available, provenance contains:

Field	What it identifies
Repository	The `owner/repository` that ran the deployment.
Commit SHA	The exact source revision associated with the release.
Ref	The branch, tag, or pull request ref used by the workflow.
Pull request	The pull request number inferred from a GitHub pull request ref.
Workflow and run	Workflow name, run ID, and retry attempt.
Actor and event	The GitHub user and event that started the workflow.

This context is attached automatically only when kite deploy runs inside GitHub Actions and the standard GITHUB_* environment variables are available. A local deployment remains valid, but it does not receive GitHub Actions provenance.

What repository access means

You select the repositories available to the GitHub App during installation. The current integration verifies the installation and records its account and repository-selection metadata. Kite does not modify source code through this integration.

The GitHub App connection is separate from GitHub OAuth used to sign in to Kite. Connecting one does not configure the other.

For a complete validation, promotion, and rollback workflow, see CI/CD and environment delivery.

PostHog

The PostHog integration enriches person profiles with the latest customer state computed by Kite. It lets product and Customer Success teams analyze behavior using shared lifecycle, health, and segment context without reproducing that logic in PostHog.

What Kite sends

Kite sends a PostHog $identify event for each changed customer. The profile update includes:

Property	Content
`kite_customer_id`	Kite's internal customer identifier.
`kite_project_id` and `kite_project_slug`	The source Kite project.
`kite_environment`	The isolated `test` or `live` environment.
`kite_lifecycle`	The customer's current lifecycle stage.
`kite_lifecycle_since`	When the current lifecycle stage began.
`kite_health_overall`	The latest overall health score.
`kite_health_components`	The component-level health result.
`kite_health_computed_at`	When health was last computed.
`kite_segments`	Current Kite segment memberships.
`kite_traits`	Only customer traits explicitly allowed in the mapping.

The PostHog distinct_id is derived from the Kite project, environment, and external customer ID. This keeps test and live identities separate and prevents two Kite projects from accidentally sharing an identity namespace.

Configure a synchronization

Select Connect PostHog in Dashboard > Integrations and authorize Kite through OAuth.
Select a Kite project and its test or live environment.
Map it to a PostHog project.
Enter the customer trait names Kite may send, such as email, name, or plan.
Enable synchronization. Kite queues an initial snapshot for existing customers in that mapping.

Mappings are scoped to one Kite project and environment. Configure test and live separately, and map them to different PostHog projects when you need strict destination isolation.

After the initial snapshot, Kite queues another profile update whenever relevant customer data changes, including traits, lifecycle, health, or segment membership.

Privacy and delivery behavior

Traits are deny-by-default: a trait is sent only when its key appears in the mapping's allowlist. Lifecycle, health, segment, project, and environment properties are part of the standard Kite snapshot.

Kite batches pending updates by PostHog destination. Temporary failures are retried with exponential backoff, while permanent client errors and exhausted retries move the snapshot to the failed queue. The integration page shows pending and failed counts and allows an owner or admin to retry failed snapshots.

Disconnecting PostHog revokes the available OAuth token, removes project mappings, deletes queued snapshots, and clears stored credentials. Tokens and PostHog project API tokens are encrypted at rest while connected.

Scope of the integration

Kite sends customer profile updates to PostHog. It does not import PostHog events, build funnels or cohorts, or replace PostHog's analytics features.

Choose the right integration

Goal	Integration
Trace a configuration version to its commit and workflow	GitHub
Audit who or what initiated a deployment	GitHub
Analyze product behavior by lifecycle or health	PostHog
Make Kite segments available on PostHog profiles	PostHog

The integrations are independent. You can use either one or both depending on your delivery and analytics workflows.