Operator CLI requests and browser login
Reuse an operator CLI profile for authenticated HTTP requests, live hub operations and a browser login link.
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
View all connections as a list
This feature uses
- Operator availability statusRelated
Browser handoff makes a connected CLI operator unavailable before disconnecting its live connection.
- INSIDE APIRequires
HTTP requests use INSIDE API operations and their existing validation rules.
- INSIDE operator CLIRequires
Requests and browser login use a saved operator CLI profile; API and hub commands also ensure a live connection.
- Logout and remembered computersRequires
Browser login reuses the current operator session rather than creating a separate credential.
- Roles and permissionsConfigured by
The operator's native API permissions still control each operation.
- Website, channel and subsite accessConfigured by
Website assignments and delegated action permissions limit the resources CLI requests can use.
Used by
- INSIDE operator CLIEnhances
A connected profile can make authenticated requests, invoke hub operations and hand sign-in over to a browser.
- INSIDE MCP test server · managed by PowerfrontEnhances
The compatibility runner uses CLI requests to create, test and remove temporary MCP service definitions.
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.