What the CLI is for
The CLI should make API-backed work easier without changing TextMine’s permission model. Common uses include:- Checking which TextMine environment and account a runtime is configured for.
- Running safe read-only checks before an integration goes live.
- Calling Public API V3 operations from scripts.
- Uploading or polling documents in trusted automation.
- Starting and inspecting task-agent work.
- Smoke-testing the hosted TextMine MCP endpoint.
- Capturing reproducible support diagnostics without exposing secrets.
How it authenticates
The CLI uses the same credentials as Public API V3 and TextMine MCP. It is not a separate access layer.| Authentication option | Use it for | Notes |
|---|---|---|
tm_... TextMine API key | Direct/private CLI use, support-led provisioning, customer-managed automation, and service-account agents. | Store it in a secret manager or local environment variable such as TEXTMINE_API_KEY. |
| OAuth bearer token | Marketplace/shared-host app flows and user-authorized environments where TextMine has enabled OAuth. | Use the OAuth flow provided by the app or setup guide. Do not paste tokens into prompts, screenshots, tickets, or source code. |
Environment configuration
Use TextMine-issued environment URLs. For the public UK multitenant deployment, the common values are:Safety model
CLI commands can represent real users or service accounts. Treat them like API and MCP tools:- Read before mutating when current state matters.
- Ask for human confirmation before creating, deleting, publishing, sending, assigning, or triggering workflow actions.
- Keep secrets out of terminal history, logs, prompts, tickets, screenshots, commits, and shared documentation.
- Prefer idempotency keys for retryable create or trigger operations when the API supports them.
- Include Vault, document, workflow, run, record, or task IDs in audit summaries.