PostHog

PASS consensus from 3 PASS.

The JavaScript Web page gives installation and initialization, then directly links its usage page for the custom capture call. The install page gives a copy-paste snippet with posthog.init('<ph_project_token>', { api_host: 'https://us.i.posthog.com', defaults: '2026-05-30' }), the JavaScript web page says the project token is found in project settings, and autocapture fires the first event on init with no extra code. Two clear install paths (snippet or npm), each using the project token from project settings; autocapture starts immediately on init, and the usage page documents posthog.capture('my event', {property: 'value'}) for custom events.

PARTIAL consensus from 3 PARTIAL.

The numeric rate and pricing tables agree, but the linked monthly query allowance has no amount or matching section on the query page. API rate limits are stated as exact numbers, but the plan quotas that cap ingestion and billing are not in the docs at all, the billing pages say only "generous free tier" and link out to the marketing pricing page for the numbers, and the API overview and the query API page describe the same query read allowance as monthly and hourly respectively. API rate limits are exact per endpoint class (analytics 240/min, CRUD 480/min, query 2400/hour, etc.), but the billing pages only enumerate one exact quota ('1M events free') and use 'generous free tier' without numbers for session replay, feature flags, and other products.

FAIL consensus from 1 PARTIAL, 2 FAIL.

The API response reference gives no 429 recovery path, and the public schema fetch failed because its response exceeded the fetch tool's 8 MB limit. This is the only documented 429 in the docs: the API overview's Responses section lists 200, 400, 401 and 503 but never 429, and none of the six other rate-limit families it names document a status code, error code, or response header, so an agent holding a 429 from the persons or insights API cannot tell which limit it hit. The main API docs page lists status codes 200, 400, 401, and 503 but omits 429 entirely. Rate limits are listed but no HTTP response code is named for exceeding them. The only 429 documentation is on the /query page for the hourly read budget (api_queries_budget_exceeded), not for the general API rate limits.

PARTIAL consensus from 2 PARTIAL, 1 FAIL.

The guide covers creation, testing, and IP allowlisting, while the linked source exposes signing without receiver-side verification instructions. Creating the destination, pointing it at your endpoint, and receiving a test POST are documented step by step, but no signature, signing secret, or verification header is documented anywhere for outgoing webhooks, the only authenticity signal offered is a list of six PostHog egress IP addresses given as a firewall allowlist, and the Authorization-header check documented at /docs/cdp/source_webhooks/source-webhook applies to incoming webhooks, the opposite direction. The webhook docs cover create, configure, test, and customize but never document how to verify the request came from PostHog. The source code template supports a signing_secret field (Standard Webhooks spec), but this is absent from the public docs page.

PASS consensus from 3 PASS.

The official posthog-js pages show capture(event, properties), matching the two-argument custom-event form in the general event guide. The posthog-js install, the send-events guide, and the usage reference all show the identical posthog.capture(name, properties) form, and the library page links the GitHub repo and the npm, Yarn, pnpm, and Bun install commands. The official SDK is posthog-js (confirmed on npm and GitHub). The docs show a complete init-to-capture path: npm install posthog-js, import, init with project token, and posthog.capture('my event', {property: 'value'}). The capture API form is consistent across the install and usage pages.