> For the complete documentation index, see [llms.txt](https://docs.scaleconnect.com.au/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.scaleconnect.com.au/api/cli/internal-cli.md).

# Internal CLI

{% @scale-docs-page-title/page-title title="Internal CLI" %}

{% hint style="warning" %}
**Confirm before publishing:** the internal CLI owner, executable name, identity provider, command allowlist, production approval flow, audit requirements, distribution and rollback. Existing development scripts and the Scalar publishing CLI are not a supported Scale operations CLI.
{% endhint %}

Internal CLI is for Scale operators managing environments, integrations and support tasks under a separately authorized identity. It is not distributed to brokers or partners.

## Access model

An operator signs in with their individual identity. Permissions are tied to role and environment. Production write commands require an explicit reason, target and approval record; they must never fall back to a global shared service secret. Every command records who ran it, when, against which resource, with which result.

## Command families

| Family        | Purpose                                    | Example form                                            |
| ------------- | ------------------------------------------ | ------------------------------------------------------- |
| `env`         | Show active environment and deployment     | `scale-internal env show`                               |
| `integrators` | Provision an integrator and inspect scopes | `scale-internal integrators get <id>`                   |
| `keys`        | Issue, rotate or revoke partner keys       | `scale-internal keys rotate <key-id> --reason <ticket>` |
| `webhooks`    | Inspect failed deliveries and replay       | `scale-internal webhooks deliveries <subscription-id>`  |
| `audit`       | Find a request or trace by ID              | `scale-internal audit request <request-id>`             |

These forms are design examples; the implementation must choose names and flags before release.

## Safe execution

Read-only commands should be available by default to the appropriate support role. Writes should show the environment, resource, planned change and a confirmation prompt. In scripts, a noninteractive approval token or ticket must be supplied rather than silently skipping confirmation. Output must redact keys, signing secrets and sensitive personal fields. The CLI should report a request or audit ID after each mutation for recovery and review.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.scaleconnect.com.au/api/cli/internal-cli.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.