# Operator CLI requests and browser login

Reuse an operator CLI profile for authenticated HTTP requests, live hub operations and a browser login link.

*Release 3.3 · developer*

## What it is

The CLI can send authenticated API requests, call operations over an operator's live connection and generate a browser login link. Each command reuses a named operator profile. The operator's existing permissions still apply.

## Who uses it and why

Developers use these commands to check an agreed integration, inspect a response or move an operator session into the browser. Ask Powerfront which API operations and hub calls are supported for your use case.

## Where to find it

Run `inside-operator help` in your terminal. The relevant help sections are **Authenticated API requests**, **Operator SignalR calls** and **Browser login**. These commands have no **Settings** menu entry.

## How it works

For an HTTP request, select the signed-in profile with `--profile` and supply a root-relative destination with `--path`. The path must begin with a single slash and stay on the profile's configured origin.

Use `api get` or `api post`, or use `api request` with `--method`. Supported methods are GET, POST, PUT, PATCH and DELETE. The CLI ensures the profile is connected and attaches its operator session to the request.

For a hub call, use `hub invoke` with `--method` and an optional JSON argument array in `--args`. The live connection must be confirmed by INSIDE. An established WebSocket connection alone is insufficient.

For browser use, run `browser login` with the profile and an optional destination in `--path`. `browser handoff` is an alias. The command returns a login link for you to open; it does not open the browser automatically. If the CLI operator is connected, the handoff marks it unavailable and disconnects its CLI connection.

The returned link contains the active session. Keep it private and use it only for your own browser handoff.

## Configure it

Pass request content with either `--body` or `--body-file`, never both. A body-file value of `-` reads the content from standard input. POST sends an empty JSON object when no body is supplied. GET does not send a request body.

The default content type is JSON; select another with `--content-type` when the agreed operation requires it. HTTP requests default to a 60-second timeout. `--timeout` is limited to 1 through 300 seconds.

Hub method names contain letters, digits or underscores and are limited to 100 characters. Arguments must be a JSON array; the default is an empty array. Argument text is limited to 1048576 characters.

Use `--json` for consistent machine-readable output on failures as well as successes. A result includes `success`, optional `data` and `error`, and `exitCode`. HTTP details include the status, reason, content type, response body and any redirect location. JSON response bodies remain structured; other bodies are returned as text.

## Limits and good to know

- Only HTTP 200 through 299 counts as a successful HTTP request. A successful HTTP response may still contain an operation-specific failure; inspect the body.
- Redirects are reported without being followed automatically.
- Request paths and browser destinations must remain on the profile's origin. Full external URLs and paths beginning with two slashes are rejected.
- The timeout setting above applies to HTTP requests. Do not assume the same limit controls hub calls.
- After a browser handoff, a later API or hub command can reconnect the CLI profile.
- If a request times out or its result is lost, check the resulting INSIDE state before repeating a change.
- A zero process exit status indicates command success. Invalid arguments normally return 2; other failures normally return 1. Invalid command-line syntax can be reported before a JSON result is produced.

## Depends on and works with

### This feature uses

- **Requires** [INSIDE API](EXT-018.md): HTTP requests use INSIDE API operations and their existing validation rules.
- **Requires** [INSIDE operator CLI](EXT-023.md): Requests and browser login use a saved operator CLI profile; API and hub commands also ensure a live connection.
- **Requires** [Logout and remembered computers](SEC-004.md): Browser login reuses the current operator session rather than creating a separate credential.
- **Configured in** [Roles and permissions](ADM-008.md): The operator's native API permissions still control each operation.
- **Configured in** [Website, channel and subsite access](ADM-009.md): Website assignments and delegated action permissions limit the resources CLI requests can use.
- **Related** [Operator availability status](CON-002.md): Browser handoff makes a connected CLI operator unavailable before disconnecting its live connection.

### Used by

- **Enhances** [INSIDE operator CLI](EXT-023.md): A connected profile can make authenticated requests, invoke hub operations and hand sign-in over to a browser.

## FAQ and troubleshooting

### Why is my request path rejected?

Use a root-relative path beginning with one slash. The CLI does not send the profile's session to another origin.

### Why does a redirect appear as a failed request?

The CLI returns the redirect status and destination without following them. Only a 200 through 299 response is treated as HTTP success.

### Why does hub invocation fail when the daemon is running?

The selected operator profile must also have a confirmed live INSIDE connection. Check its session status and the error, then confirm the operation name, arguments and permissions.

### Why did browser login disconnect the CLI operator?

Handoff marks a connected CLI operator unavailable and closes its live CLI connection before returning the login link. Open the link to continue in the browser.

### Does browser login create a separate session?

It reuses the profile's existing session. An expired or revoked session can still fail when you open the link. Sign in again and generate a fresh link if needed.

### Can I pass both body options?

No. Choose `--body` for inline content or `--body-file` for file or standard-input content.
