feat: add secret_key config, deprecate personal_api_key#727
Conversation
|
posthog-python Compliance ReportDate: 2026-07-07 14:47:40 UTC ✅ All Tests Passed!111/111 tests passed Capture_V1 Tests✅ 94/94 tests passed View Details
Feature_Flags Tests✅ 17/17 tests passed View Details
|
The local feature flag / remote config credential now accepts either a Personal API Key or a Project Secret API Key, so the field is renamed to secret_key. personal_api_key is kept as a deprecated alias that resolves into secret_key, with a DeprecationWarning, so existing code keeps working.
394b812 to
6034978
Compare
- Regenerate public API snapshot for the new secret_key field - Update the unauthorized-error test to assert secret_key - Collapse the three secret_key tests into one parameterized table - ruff format
…ey-to-secret-key # Conflicts: # references/public_api_snapshot.txt
Second assertion (in test_feature_flags) still pinned the old personal_api_key wording after the message was renamed to secret_key.
|
Reviews (2): Last reviewed commit: "test: assert secret_key in wrong-key err..." | Re-trigger Greptile |
|
Marked ready for review. Naming is settled — this is a generic Merge timing still coordinates with the project-secret-key rollout (feature-flagged today) — ready-for-review ≠ merge-now. |
dustinbyrne
left a comment
There was a problem hiding this comment.
some lingering references
$ git -P grep -l 'personal_api_key' -- . ':(exclude)references/**'
.env.example
example.py
examples/async_redis_flag_cache.py
examples/celery_integration.py
examples/redis_flag_cache.py
examples/remote_config.py
openfeature-provider/openfeature/contrib/provider/posthog/provider.py
openfeature-provider/tests/conftest.py
openfeature-provider/tests/test_provider_unit.py
posthog/__init__.py
posthog/ai/prompts.py
posthog/client.py
posthog/flag_definition_cache.py
posthog/request.py
posthog/test/ai/test_prompts.py
posthog/test/test_client.py
posthog/test/test_client_fork.py
posthog/test/test_feature_flags.py
posthog/test/test_flag_definition_cache.py| secret_key=None, | ||
| personal_api_key=None, |
There was a problem hiding this comment.
this is a breaking change if anyone is using positional arguments in the client constructor
given how many we have, it seems unlikely, but there's no downside to moving this addition to the end
There was a problem hiding this comment.
Done — moved secret_key to the end of the constructor params (2b87f8a) so no existing positional argument shifts. Thanks!
Avoids shifting the positional order of existing constructor parameters (non-breaking for any positional callers), per review feedback.
…ey-to-secret-key # Conflicts: # posthog/client.py # references/public_api_snapshot.txt
Problem
The credential used for local feature flag evaluation and remote config accepts either a Personal API Key (
phx_...) or a Project Secret API Key (phs_...), but the config field is namedpersonal_api_key. Passing a project secret key to a field called "personal api key" is confusing now that project secret keys exist.Change
secret_keyas the canonical config field — accepts a Personal API Key or a Project Secret API Key.personal_api_keyas a deprecated alias that resolves intosecret_key. Non-breaking: existing code keeps working and gets aDeprecationWarning.secret_keywhen both are provided.secret_key.Context
From the Slack discussion + PostHog/posthog-js#4046. This covers the rename only. The other two items from that thread — making flag refresh opt-in, and a config to enable/disable local eval independent of the env var — are separate.
Part of a coordinated rename across the backend SDKs (python, node, php, ruby, go, dotnet, rs).