OnePin uses API keys for all programmatic access (SDK and CLI). Browser-based access uses Clerk session tokens, which are not covered here.
Keys are 32-character base62 strings prefixed op_live_:
v0.2: Test-environment keys (op_test_*) are not yet available.
The plaintext value is shown exactly once. Store it in a secrets manager or environment variable immediately.
The CLI and SDK resolve credentials from three sources, in priority order:
If no key is found from any source, the SDK raises OnePinConfigurationError and the CLI exits with an error.
onepin login writes a TOML credentials file at ~/.onepin/credentials:
File permissions are enforced on write: 0600 on the file, 0700 on the ~/.onepin/ directory. The SDK and CLI refuse to load credentials from a world-readable file.
v0.2: Named profiles (--profile staging) are not yet implemented. The [default] profile is the only one used in v0.1.
Select the minimum set of scopes your key needs.
Cloning a template into a workflow requires workflows:write — the clone creates a new workflow in your workspace.
Rotate keys every 90 days or immediately after any suspected exposure:
ONEPIN_API_KEY in your CI secrets or secrets manager.onepin whoami.Never commit keys to source control. Add ONEPIN_API_KEY to .gitignore and use .env files only for local development.
Each key is bound to a single workspace at creation time. All resources created via that key — workflows, uploads — belong to that workspace. To operate on a different workspace, create a key under that workspace.
The X-Workspace-Id header is optional on API calls made with an API key; the server derives the workspace from the key. If you supply the header, the value must match the key’s bound workspace or the request is rejected with 403.