posthog-rs

posthog-rs is PostHog’s official Rust SDK for sending analytics events, capturing errors, and evaluating feature flags from Rust applications and services. It offers both blocking and async (Tokio) clients, local feature-flag evaluation to avoid a network round-trip per check, and built-in retry/compression handling for reliable event delivery.

As the Rust-native client for the PostHog product-analytics and feature-flagging platform, posthog-rs targets backend services, CLIs, and systems software that want first-class event tracking and flag evaluation without shelling out to another language’s SDK.

What You Get

• Both blocking (std-based) and async (Tokio) client variants sharing the same API surface
• Event capture with automatic retry, gzip/brotli/zstd compression, and batching support
• Feature flag evaluation against the PostHog API, plus local evaluation mode using a downloaded flag definition to avoid per-check network calls
• Built-in error tracking capture (error_tracking.rs) for reporting Rust panics/errors as PostHog events
• A global client singleton (global.rs) for simple fire-and-forget capture calls from anywhere in an app

Common Use Cases

• Instrumenting a Rust backend service to send product-analytics events to PostHog
• Evaluating feature flags server-side in a Rust API to gate functionality per user/organization
• Capturing Rust panics and errors as PostHog error-tracking events for observability
• Using local feature-flag evaluation in latency-sensitive Rust services to avoid a network call per flag check

Under The Hood

Architecture: The crate is split into a client/ module implementing blocking and async HTTP clients against PostHog’s capture and decide/flags endpoints (endpoints.rs), a feature_flags.rs/local_evaluation.rs pair separating remote flag evaluation from a locally-cached evaluation path, and dedicated event.rs/event_v1.rs modules handling the two generations of PostHog’s event capture API. Tech Stack: Built on reqwest (rustls-backed, blocking and async features) for HTTP, serde/serde_json for payloads, tokio (optional) for the async client, chrono/uuid (v7) for timestamps and IDs, and optional brotli/zstd/flate2 compression backends, targeting Rust 1.78+. Code Quality: The tests/ directory has broad coverage split by concern — blocking vs async transport, immediate vs batched capture, v0 vs v1 API retry behavior, local evaluation, panic capture, and error tracking — indicating deliberate regression coverage across the SDK’s multiple API generations. API Design: The client exposes a consistent builder pattern (derive_builder) for client configuration and largely mirrors PostHog’s other official SDKs’ method names (capture, identify, feature flag evaluation), making it approachable for teams already using a PostHog SDK in another language.