GetPageTrackingAPI mirrors the erdo_get_page_tracking MCP tool: read which
analytics destinations the caller org’s published pages send visitor data to. The companion read to /v1/page-analytics/query — that endpoint reports what visitors did, this one reports whether anything was tagging them, which is the difference between “376 engaged sessions, retarget them” and discovering no pixel was ever firing.
Returns only public, client-side identifiers (the `phc_…`/`G-…`/pixel-id values already embedded in published page JS); the provider’s internal numeric project id is stripped here. Read-only by design: destinations are Erdo-provisioned into the account that must be able to use them, never caller-chosen.
These are the vendor destinations stored on the organization. Erdo’s own first-party page-events beacon is provisioned per page at render time and is not among them, so an empty list means no vendor tracking rather than no recording.
Authorizations
An Erdo API key (erdo_api_...) or scoped token (erdo_token_...).
Response
Success response
banner. With "required", low or absent event volume can be a consent gate rather than absent traffic.
enabled or not — the third-party analytics a published page is wired to send to. Erdo's own first-party page-events beacon is deliberately not among them: it is provisioned per page on first render rather than stored on the org, so an empty list here means no vendor tracking, NOT that nothing is recording. The beacon is what page-event queries read, and it runs independently.
so a consumer building a replay-backed surface needs to know whether the recordings it is about to show were masked at capture time.

