Is it safe to share a PostHog personal API key with another tool?

From the SoleOS answers series — written about our own product space; grounded in published definitions and documented behavior, never invented numbers.

Sharing a PostHog personal API key with another tool is safe only if you scope it tightly, know exactly what it can read, and can revoke it independently of your other keys — by default, PostHog personal API keys are broad and tied to your user account, not to a single project, so the honest answer is "it depends on how you set it up," not a flat yes.

That's not a dodge. It's the actual mechanic of how PostHog auth works, and it's worth understanding before you paste a key into a growth dashboard, a Zapier flow, or a metrics tool.

What a PostHog personal API key can actually do

PostHog has two relevant auth concepts, and mixing them up is where most of the risk comes from:

• Personal API keys are created under your user account (Settings → Personal API Keys). By default they can act across every organization and project your user has access to, with whatever permissions your user role has. That can include reading raw events, reading and writing feature flags, reading cohorts and person profiles, and in some scopes, deleting data.
• Project API keys (the ones used in your client-side SDK, like phc_...) are write-only for event ingestion and are meant to be public. These are not the concern here.

The personal API key is the one people mean when they ask "is it safe to share this." And the answer depends almost entirely on whether you scoped it down before handing it over.

Scope it before you share it, not after

Modern PostHog lets you restrict a personal API key at creation time to:

• Specific scopes (e.g., read:events, read:insight, read:project — no write, no person-level access)
• Specific projects, rather than every project under your account
• An expiration date, so it self-destructs instead of living forever in someone else's config

If you're generating a key for a third-party dashboard or metrics tool, the checklist is:

1. Pick the narrowest read scopes that satisfy what the tool needs (usually just insights/events aggregates, not raw person data).
2. Limit it to the one project the tool actually needs — not "all projects," which is the default if you don't touch that setting.
3. Set an expiration if the tool supports rotating keys, so you're not maintaining a permanent unscoped credential in a third-party system's database.
4. Name the key after the tool that's using it ("Connector — [tool name]"), so when you audit your keys list in six months you know what's safe to revoke.

If a tool asks for a personal API key and doesn't tell you which scopes it needs, that's worth a support email before you hand one over. A tool that only needs aggregate metrics has no reason to ask for person-level read access or write scopes.

OAuth vs. API key: why the auth method matters

Where a connector supports OAuth instead of a raw key, that's generally the safer default — not because OAuth is magic, but because it puts the scoping and revocation in PostHog's hands rather than yours. With OAuth, you approve a specific set of permissions during the connect flow, and you can revoke access from PostHog's side without needing to remember to go delete a key later. With a manually pasted personal API key, revocation is 100% on you, and it's easy to forget a key exists once the integration is working.

This is exactly why SoleOS's PostHog connector supports both OAuth and personal API key, and defaults to OAuth where possible — it's less for the founder to track. You can see the exact scopes any connector requests, PostHog included, on what SoleOS connects to (scopes + revocation).

What actually needs to leave PostHog

Before scoping anything, it helps to separate what a dashboard tool is for from what PostHog is for. If you're pulling metrics into a portfolio view — signups, activation events, retention curves across several products — you almost always only need aggregate, read-only access to insights and event counts. You do not need write access, feature flag control, or person-level identity data for that use case.

If a tool is asking for more than that, ask why. Legitimate reasons exist (e.g., a tool that manages your feature flags on your behalf needs write access to flags — that's its job). But a metrics dashboard asking for write scopes or full person data access is asking for more blast radius than its function requires.

When you don't need this level of caution

If you're the only person who will ever see the dashboard, you're connecting a single low-traffic side project, and you're comfortable rotating the key yourself every few months, a broadly-scoped personal API key is a manageable risk for a solo operator — it's not the same threat model as handing credentials to a team of contractors. The caution above matters more as you connect more products, more tools, and especially if anyone else (a contractor, a co-founder, a VA) has access to the tool you're connecting it to. For a single hobby project's read-only stats, don't let scope anxiety stop you from getting the data you need — just don't leave the key unscoped and un-rotated for years.

How this fits a multi-product setup

If you're running more than one app and want PostHog activation and retention numbers sitting next to Stripe or RevenueCat revenue, GA4 traffic, and App Store or Play Store installs in one place, that's the exact use case SoleOS is built for — this post itself is written by SoleOS about its own space, so take the framing with that in mind. It won't tell you PostHog's key model is bad or good; it's just how the tool works, and knowing it protects you regardless of what you connect it to.

If you're deciding whether PostHog and GA4 disagree on visitor counts before you even get to the key-sharing question, that's a separate rabbit hole — see why GA4 and PostHog report different visitor numbers for the mechanics. And if you're stitching together revenue sources alongside behavioral analytics, tracking Stripe and RevenueCat together covers the same scoping questions in a billing context.

Full details on exactly which scopes SoleOS requests from PostHog, and how to revoke access, live on the security overview and the connectors page. You can also see how the connected metrics actually render — no PostHog key required — in the live demo.

Frequently asked questions

Can a personal API key read my users' identities?

Yes, if the scope includes person or cohort reads. PostHog stores identified user properties (email, distinct IDs, custom properties) as part of person profiles, and a broadly scoped key can read those. If a connector only needs aggregate counts and trends, restrict the key to event/insight read scopes and leave person-level scopes off.

What happens if I revoke a personal API key a tool is using?

The tool's next API call with that key fails — usually returning a 401 — and any dashboard relying on it stops refreshing until you generate a new key and update the connection. This is generally the safe way to cut off a connector you no longer use, but it's manual: you have to remember which key belongs to which tool, which is why naming keys by their purpose matters.

Is it safer to use PostHog's OAuth flow instead of a personal API key?

Generally yes, where a tool supports it. OAuth lets you see and approve the exact scopes requested at connect time, and revocation happens from PostHog's own settings rather than relying on you to delete a key manually. It doesn't change what data flows once connected — it changes how easy oversight and revocation are.

Do I need a separate PostHog key for each product in my portfolio?

Not necessarily — PostHog projects can share an organization, and a key can be scoped to multiple specific projects rather than "all projects." For a multi-product portfolio, it's still worth using project-scoped keys (or OAuth with per-project selection) rather than one all-access key, so a compromised or leaked credential only exposes one product's data rather than your entire portfolio.

Does connecting PostHog to a metrics tool let that tool train AI models on my data?

That depends entirely on the tool, not on PostHog — check the tool's own AI policy. SoleOS, for example, only sends aggregated project metrics and project names to its AI provider (Anthropic), never raw events or end-user identities, and does not use customer data to train models; see how SoleOS uses AI for specifics.