​

Data destinations

A data destination continuously syncs a Latitude project’s data into a system you own — your analytics tool, your data warehouse, your object storage. Connect a destination once and new data keeps flowing to it within minutes, with no exports to schedule and no pipeline to maintain. The data Latitude can send grows over time. Today that’s your traces and spans; the same engine is built to forward other entities Latitude generates — like signals — as they become available. The first supported destination is PostHog LLM Analytics: your Latitude spans show up as native $ai_* events in your own PostHog project, so you can analyze cost, latency, and usage alongside the rest of your product data. Destinations are bring-your-own: you point Latitude at your own PostHog project with your own API key. Latitude never sends your data anywhere you didn’t connect.

​

Supported destinations

​

Available sources

A source is the kind of telemetry a destination receives. Today every destination reads spans; the rest are directions we’re exploring. With PostHog, traces and sessions don’t need their own source: each span carries its trace and session identifiers, so PostHog reconstructs the full trace and session views for you automatically.

​

Connect a destination

Open your project’s Settings → Data destinations and create one. For PostHog you’ll provide:

• Region / host — PostHog US (us.i.posthog.com), PostHog EU (eu.i.posthog.com), or a custom host for self-hosted PostHog.
• Project API key — your PostHog project key (phc_…).
• Name — a label to recognize the destination by.
• Exclude payloads — see Excluding payloads below.

Before saving, use Test connection to confirm Latitude can reach PostHog and your key is accepted.

​

What lands in PostHog

Each Latitude span becomes a native PostHog LLM Analytics event:

• $ai_generation — an LLM call (with token counts and cost in USD)
• $ai_embedding — an embedding call
• $ai_span — any other step, such as a tool call or retrieval
• $ai_trace — emitted for the root step, so the trace view is populated

Events carry the trace, span, parent, and session identifiers (so PostHog groups them correctly), latency, model and provider, and cost. They also include latitude_project_id and latitude_span_url so you can jump from a PostHog event straight back into Latitude.

​

Excluding payloads

Turn Exclude payloads on when you don’t want prompt and completion content leaving Latitude. It nulls every content-bearing field — inputs, outputs, tool definitions, and error messages (replaced by an error type only). Everything non-sensitive still flows: token counts, cost, latency, model and provider, identifiers, and timing. This is useful when content is subject to compliance constraints but you still want the metrics.

​

How delivery works

• Near real-time. New data is delivered continuously, on a short interval, so it shows up in your destination within minutes — not on a manual export.
• No duplicates. Delivery is at-least-once and idempotent: each event has a stable identity, so retries and overlapping windows never duplicate data in your destination.
• Pause and resume. Pause a destination anytime; while paused nothing is sent. On resume, Latitude catches up the backlog it missed.
• Backfill. When you connect a destination you can also import past traces, so your destination isn’t limited to data created after you connected it. How far back you can reach is bounded by your plan’s data retention.