fix(flags): Rename to project_api_key

[haacked]

PR #36154 added deterministic routing using a new project_api_token parameter in the body. But I intended the parameter to match the existing api_key parameter, but with aproject_ prefix (aka project_api_key). In fact, I implemented it that way in the posthog-python library.

Problem

I confused myself and used the wrong name. Since this is a new parameter, it doesn't break anybody.

Changes

Rename project_api_token to project_api_key as the key and in the method name.

How did you test this code?

Unit tests.

👉 Stay up-to-date with PostHog coding conventions for a smoother review.

[greptile-apps]

Greptile Summary

This PR performs a straightforward parameter rename from project_api_token to project_api_key in the routing API system. The change affects two files: posthog/api/routing.py and its corresponding test file posthog/api/test/test_routing.py.

The routing system was recently enhanced in PR #36154 to support deterministic routing for URLs containing @current as the team ID. This feature allows clients to pass a project API key in the request body to help the system route to the correct team. However, the developer initially named the parameter project_api_token but intended it to follow the existing naming convention of the api_key parameter with a project_ prefix, resulting in project_api_key.

The changes are purely cosmetic - renaming the parameter key in the request data lookup, updating the method name from _get_explicit_project_api_token() to _get_explicit_project_api_key(), and updating all associated test methods, docstrings, and test data. The core functionality remains identical, maintaining the same logic for extracting the project API key from POST/PUT/PATCH request bodies to enable deterministic routing.

This change aligns the backend API with the posthog-python client library implementation, which was already using the correct project_api_key naming convention. Since this parameter was recently introduced and likely has minimal adoption, the rename maintains consistency across the PostHog ecosystem without significant breaking change impact.

Confidence score: 5/5

• This PR is extremely safe to merge with virtually no risk of production issues
• Score reflects a simple parameter rename with comprehensive test coverage and no logic changes
• No files require special attention as the changes are straightforward cosmetic updates

_{2 files reviewed, no comments}

_{Edit Code Review Bot Settings | Greptile}