Docs

PostHog Capture V1 Endpoint Tracking

PostHog's Node SDK can now send events to the Capture V1 endpoint. Track delivery, retries and property changes before you switch it on.

Analytics

Many mobile teams send some of their most valuable events from a server: purchases confirmed by a payment webhook, subscription renewals, account upgrades. These server-side events are often the ones your revenue reporting depends on, which is why a change to how they are delivered deserves attention before it reaches production.

On 11 July 2026, PostHog released posthog-node 5.41.0, adding opt-in support for a new ingestion route. Set the environment variable POSTHOG_CAPTURE_MODE=v1 and the SDK submits events to the Capture V1 endpoint instead of the legacy /batch/ endpoint. The default stays on the legacy behaviour, so nothing changes until you choose it.

According to the release, Capture V1 routes to /i/v1/analytics/events, uses Bearer authentication, reorganises properties into typed objects, and retries per event with exponential backoff. The SDK also keeps $ai_* events on a separate queue that never shares a batch with the V1 queue, so a failure in one cannot cascade into the other.

Why This Matters

Without a plan, a delivery change like this can go wrong quietly. If property handling differs, a chart that filters on a specific property may start returning fewer rows. If retry behaviour differs, you may see more late events, or in edge cases duplicates. Because the switch is one environment variable, it is easy to flip in a single service and forget to tell the analysts who read the data.

Data Points to Track

Add these properties to your server-side events, or measure them in your warehouse:

  • capture_mode: v0 or v1, set from your own configuration so every event is labelled
  • sdk_version: the installed posthog-node version
  • service_name: which backend service sent the event
  • event_name: to compare volumes per event type across modes
  • send_attempts: how many tries were needed before success
  • delivery_delay_seconds: time between the event occurring and it being ingested
  • failed_event_count: events dropped after retries are exhausted
  • property_completeness: the share of events carrying each required property

Setup Steps

  1. Choose one low-risk service to trial first, rather than switching every backend at once.
  2. Record two weeks of baseline volumes per event name and per key property from that service.
  3. Add capture_mode as a property on every event that service sends, set to v0 for now.
  4. Upgrade posthog-node to 5.41.0 or later in a staging environment and confirm events still arrive.
  5. In staging, set POSTHOG_CAPTURE_MODE=v1, send a known test set of events, and compare properties field by field against the legacy output.
  6. Roll v1 out to the trial service in production, changing the capture_mode label at the same time.
  7. Build a dashboard comparing event counts, property completeness and delivery delay by capture_mode, and keep it for at least two weeks.

Actionable Insights

Compare like with like. If event counts differ by more than normal daily variance, look at property mapping first. A renamed or restructured property is a more common cause than lost events.

Read the retry data. A rising send_attempts average tells you your network path or ingestion is under strain, even when nothing is being dropped yet.

Protect your revenue reports. Reconcile server-side purchase events against your payment provider’s records for the trial period. A matching total is the strongest evidence that the switch is safe.

Keep AI events separate in your analysis. Because $ai_* events use their own queue, check that their volumes and latency are tracked on their own, not blended with product events.

Roll back with confidence. Since the setting is an environment variable, reverting is quick. Labelled events mean you can always tell which period used which mode.

Expert help

Need help tracking this in your app?

Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.

Talk to an expert