Repository navigation
feat(MBL-2330): one-key CustomerIO client - #254
Conversation
new CustomerIO({ apiKey }) sends tracking to the Track API and transactional
sends to the App API, both with the key as Bearer. ak_us_/ak_eu_ keys pick
the region; an explicit region wins; legacy keys keep the US default.
A wk_ key throws KeyCapabilityError on transactional calls before any
request, and a 401/403 from either API is rethrown as KeyCapabilityError.
TrackClient and APIClient are unchanged. README now leads with CustomerIO
instead of the CDP client.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Tested locally at this PR's head (
No key showed up in the SDK's output or logs. All passed. |
Shahroz16
left a comment
Shahroz16
left a comment
There was a problem hiding this comment.
Approving from my side. A couple of small follow-ups:
Could we make the 401/403 message a bit more general? A valid key can get those for an IP restriction or a disabled workspace too, so “this key can't…” can send someone looking at key permissions when that may not be the issue. Keeping the original error is helpful; I think this just needs clearer wording.
Also, could we qualify “Legacy App API keys also work here” in the README? They work for transactional calls, but Bearer Track calls on Pipelines workspaces need a source-bound new key.
That's my take. Let's also get Bernard or the NF team to review this.
Read the region from any key shaped {xx}_{us|eu}_ and treat pk_ as the
public key.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ly pk_/sk_ Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
|
The 401/403 message now says the server refused the request and points to the key type, IP restrictions and workspace status, with the original error kept as |
Shahroz16
left a comment
Shahroz16
left a comment
There was a problem hiding this comment.
One thing I'd like fixed here: App API refusals lose the server's message. Plus a smaller region case. Details inline.
That's my take.
…ees with the key Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Shahroz16
left a comment
Shahroz16
left a comment
There was a problem hiding this comment.
Looks good to me. App API refusals now carry the server's reason, and a mismatched region or a non-https URL fails up front. One small README note inline, not blocking.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Shahroz16
left a comment
Shahroz16
left a comment
There was a problem hiding this comment.
Looks good to me. The README matches the code now.
Adds a one-key client for the new secret
sk_API keys.sk_key covers Track and the App API, sent as a Bearer token.sk_us_…/sk_eu_…).pk_keys are refused for App API calls, since they are for tracking only.