🦔 PostHog provides open-source web & product analytics, session recording, feature flagging and A/B testing that you can self-host. Get started - free.
The PostHog JS SDK patches the HTTP clients such as fetch and sets a header with the current $session_id and $window_id (also the timestamp optionally) if the session recording is running.
Let's call this header POSTHOG_RECORDING -> sessionId_123, windowId_456.
If the backend is using a PostHog SDK, the SDK hooks up on requests via interceptors and reads the POSTHOG_RECORDING header.
The $session_id and $window_id are then set to all captured events automatically for that request.
When using the PostHog JS SDK, you can call posthog.get_session_replay_url and read the current URL
You can also read the $session_id calling posthog.get_session_id but you cannot read the $window_id currently, so the get_session_replay_url is the only alternative for now.
Set this URL as a header for all HTTP calls, let's call the header POSTHOG_RECORDING_URL.
If the backend is using a PostHog SDK, the SDK hooks up on requests via interceptors and reads the POSTHOG_RECORDING_URL header.
Set the Recording URL to all captured events for that request.
This URL can also be set to an error monitoring tool such as Sentry
Additional context
Instead of defining PostHog headers, we could use standard headers for this type of context such as
trace-contextbaggage
Is your feature request related to a problem?
I'd like to see the events captured on the backend when watching a session recording from my front end.
https://posthoghelp.zendesk.com/agent/tickets/9883
Describe the solution you'd like
Everything works automagically.
The PostHog JS SDK patches the HTTP clients such as
fetch
and sets a header with the current$session_id
and$window_id
(also the timestamp optionally) if the session recording is running.Let's call this header
POSTHOG_RECORDING
->sessionId_123, windowId_456
.If the backend is using a PostHog SDK, the SDK hooks up on requests via interceptors and reads the
POSTHOG_RECORDING
header.The
$session_id
and$window_id
are then set to all captured events automatically for that request.$session_id: sessionId_123
$window_id: windowId_456
Describe alternatives you've considered
You can do this manually.
When using the PostHog JS SDK, you can call
posthog.get_session_replay_url
and read the current URLYou can also read the
$session_id
callingposthog.get_session_id
but you cannot read the$window_id
currently, so theget_session_replay_url
is the only alternative for now.Set this URL as a header for all HTTP calls, let's call the header
POSTHOG_RECORDING_URL
.If the backend is using a PostHog SDK, the SDK hooks up on requests via interceptors and reads the
POSTHOG_RECORDING_URL
header.Set the Recording URL to all captured events for that request.
This URL can also be set to an error monitoring tool such as Sentry
Additional context
Instead of defining PostHog headers, we could use standard headers for this type of context such as trace-context baggage
Somehow relates to https://github.com/PostHog/posthog/issues/8183
https://posthog.com/docs/session-replay/troubleshooting#filtering-cant-find-my-custom-events
Thank you for your feature request – we love each and every one!