Apps, keys, and environments
Choose the right credentials for traces, datasets, and evaluation reports.
A workspace contains apps. An app has a display name and an immutable
serviceName. Initialize LedgeClient with that exact service name.
Each app has Test and Live environments. A key binds one app, one environment, and one access type. The key determines where an upload belongs; the SDK does not have a separate environment switch.
| Task | Credential |
|---|---|
| Upload traces | Write key |
| Upload evaluation reports | Write key |
| List or retrieve traces | Read key |
| Download a dataset | Read key from either Test or Live in the dataset's app |
Write keys cannot read, and read keys cannot upload. Dataset collections are shared across the app's environments; direct trace reads remain scoped to the key's environment.
Create a key
In the console, select the app and environment, open Keys, and create a key with the appropriate access. Copy the complete token when it is first shown. Subsequent key listings show metadata rather than its secret.
Tokens have this shape:
lk_test_write_<public-id>.<secret>For local integration, supply a test write key through development configuration.
For shipped applications, use your own credential retrieval through
LedgeCredentials.tokenProvider. The SDK invokes your provider when it needs a token; it does
not supply a credential-issuing backend. A static key embedded in an app can be
extracted from that app.
Rotate a key
Create a replacement key for the same app/environment/access, update your credential source, and verify delivery before revoking the previous key in the console. Existing trace identity and environment remain the same when uploads retry through a replacement write key.
Invalid, expired, revoked, and disabled-app keys are rejected. A valid key with the wrong access type is also rejected. See HTTP authentication.