Repository navigation
feat(MBL-2330): one-key CustomerIO client - #254
sydneycollins-cio wants to merge 2 commits into
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.
This branch has not been deployed
2 participants
Update to support the new private key