splitchCredentials.
Client Key evaluates, API Key peeks. Pass exactly one.
Construct the client with exactly one credential. Zero or both throws SDK_CREDENTIAL_CONFIGURATION_INVALID at construction, because the two unlock different methods and the client cannot guess which you meant.
| Option | Credential | Where it may live | Unlocks |
|---|---|---|---|
clientKey | public Client Key (pk_) | browsers, mobile, servers: anything that evaluates | evaluate, evaluateDetails, verify, evaluateAll, track |
apiKey | secret API Key (sk_) | servers only; never ship it to a client | peekVariant, verify, evaluateAll, track |
A server-side integration that fires Exposures uses a Client Key, not an API Key. The API Key cannot call evaluate or evaluateDetails. Client Keys are safe to use from servers, so present one on that path.
Scopes
The data plane has two scopes. A Client Key carries both of them, which is why it can track as well as evaluate. An API Key carries whichever you enumerate at splitch api-keys create, so an API Key minted for evaluation alone is refused by track.
| Scope | Covers |
|---|---|
data-plane:evaluate | evaluate, evaluateDetails, peekVariant, verify, evaluateAll |
data-plane:write | track, the Metric Event append |
What a rejected credential looks like
- UNAUTHORIZED: no credential, or one that could not be parsed.
- CREDENTIAL_REVOKED: known key, revoked. Revocation is immediate; it never degrades to cached service.
- INSUFFICIENT_SCOPES: valid key without the scope this call needs. The failure names
requiredScopesand the scopes the key actually holds. - ORIGIN_NOT_ALLOWED: valid Client Key from an origin not on its allow-list.
- APP_MISMATCH: the key belongs to a different App than the request addressed.