[sydneycollins-cio]

Adds a one-key client for the new secret sk_ API keys.

• One sk_ key covers Track and the App API, sent as a Bearer token. Both APIs use an explicit auth handler, so a .netrc entry can't replace it.
• The region comes from the key (sk_us_… / sk_eu_…).
• Public pk_ keys are refused for App API calls, since they are for tracking only.
• Legacy keys still work for App API calls. Pipelines tracking needs a source-bound sk_ key.

[sydneycollins-cio]

Tested locally at this PR's head (851a0b71cd) against services 199c4a789c, CDP aa721dbec and edge af983b44, all at main. Keys were made through services' UI API and synced to CDP and edge the normal way. A pass-through proxy recorded the auth scheme and status. CDP ran in strict mode, so a bad key gets an error instead of 200.

Key	Call	Result
ak_	identify	Bearer, 200
ak_	track event	Bearer, 200
ak_	send email	Bearer, 200 on /v1/send/email
wk_	identify	Bearer, 200
wk_	send email	refused by the SDK (no transactional access), no request sent
legacy App API key	send email	Bearer, 200
legacy site ID + API key	old Track client identify	Basic, 200
revoked ak_	identify	401, SDK reports the key can't use Track

No key showed up in the SDK's output or logs. All passed.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 851a0b7. Configure here.}

[Shahroz16]

There's also a .netrc case in _BearerTrackClient: setting session.auth = None lets Requests replace the supplied Bearer header with Basic auth if there's a matching entry for the API host. Could we use an explicit Bearer auth handler and cover that with a prepared-request check? It only happens with that matching entry, but we'd still be sending different credentials from the ones the caller passed.

Two smaller wording follow-ups: 401/403 can also mean an IP restriction or a disabled workspace, so “this key can't…” is a bit too specific. And the README should qualify legacy-key support: transactional calls work, but Bearer Track calls on Pipelines workspaces need a source-bound new key.

I'd like us to sort out the URL handling in the existing thread and this auth case before merging. That's my take. Let's also get Bernard or the NF team to review this.

[sydneycollins-cio]

Addressed the review in 72295df:

• The track client sends the key through a Bearer auth handler, so a matching .netrc entry no longer swaps in Basic auth. A test checks the prepared request keeps Bearer <key>.
• 401/403 messages no longer say "this key can't". They say the request was refused and to check the key, permissions, IP allowlist and workspace status.
• README notes that legacy keys still work for App API calls, but Pipelines tracking needs a new source-bound sk_ key.
• The trailing-slash URL fix (c103316) is still in place.

[Shahroz16]

Could we limit the .netrc guarantee in the description to Track? send_* still uses the existing header-only APIClient, so a matching entry for the App API host replaces its Bearer header with Basic auth.

[sydneycollins-cio]

The description now limits the .netrc guarantee to Track calls, and says send_* still uses the header-only client.

[Shahroz16]

One case I'd like us to fix before this goes in: a key with a trailing newline ends up in the exception message. A couple of smaller ones inline.

That's my take.

[Shahroz16]

Looks good to me now. The key is stripped, send_* goes through the Bearer auth handler too, and both URL overrides are checked.