RUN
URL-native execution: the relative URL is resolved against the currently connected API (CONNECT API <api>:<environment>; first); RUN never takes an explicit API/environment clause of its own. HTTP_METHOD is optional and defaults to GET; DELETE/POST/PUT/PATCH/HEAD/OPTIONS and other configured methods can be given explicitly, e.g. RUN DELETE /api/customer/123;. A :name segment/query value is resolved, in order: a matching session VAR, the current API environment's own variable, this endpoint's persisted CONFIG API value, its configured default, or a clear missing-parameter error; a literal value (e.g. 123) is used directly. ${name}/{{name}} (API/environment variable templating, the same syntax already used inside a stored endpoint's own definition) also resolves directly in the typed URL now, against the connected API's active environment, before endpoint matching happens (so it can affect which endpoint a URL matches). ${ENV:NAME} reads an operating-system environment variable at invocation time instead (undefined fails explicitly, never silently substitutes an empty string); this is a different, unrelated namespace from ${name}. An endpoint's id, alias (CONFIG API), or name is a completion/discovery shortcut only: RUN <reference>; with no query/tab-expansion is rejected with a hint toward SYNTAX <reference>; or RUN <reference><TAB>, never executed directly. Most imported endpoints never have an alias set at all, only a name and a numeric id, and completion works from any of the three. Query parameters are URL-native: only what is written in the URL is sent (plus any required parameter with no value in the URL that can still be resolved via VAR/persisted/default), never a configured-but-unmentioned optional query parameter. The optional trailing TABLE/RAW clause selects the response rendering exactly as before; the default remains a complete LIST view.
Arguments
[HTTP_METHOD] <relative-api-url> (mandatory; HTTP_METHOD optional, defaults to GET; the URL is resolved against the active CONNECT API session); TABLE or RAW (optional, trailing, mutually exclusive; default is a complete LIST view)
Examples
RUN /api/customer/123; RUN /api/customer/123?expand=mail&showall=true; RUN DELETE /api/customer/123; RUN /api/customer/:id; RUN /api/customer/${ENV:CUSTOMER_ID}; RUN /api/customer/${customerId}; RUN /api/customer/123 RAW;
Notes
RUN [HTTP_METHOD] <relative-api-url> [TABLE|RAW]; - SPRINT XT02A (URL-Native API Execution), the sole canonical execution command, replacing this class's own earlier id/alias-based grammar (API Quality and UX Consolidation sprint, 2026-09-14).
This is an intentional, documented breaking change (docs/TECHNICAL_CHANGE.md): the previous RUN <endpointId-or-alias> [API <apiId>] [ENV <environment>] [TABLE|RAW]; grammar is fully replaced, not extended - RUN CUST; (a bare alias) is no longer executed and is now explicitly rejected with a hint toward SYNTAX/tab-completion (section 2.3), and RUN no longer accepts explicit API <apiId>/ENV <environment> clauses - the active CONNECT API session is now the sole source of execution context (section 2.4/3.1). The retired, hidden EXECUTE API ENDPOINT keyword (CommandApiExecuteEndpoint) is left untouched as a legacy/compatibility execution path (spec section 23, point 2/3) - it is not part of this class and shares no code with it.
HTTP_METHOD is optional and defaults to GET (section 2.2). The URL is resolved against the currently connected API (section 2.4) - RUN fails clearly if none is connected. A :name path/query placeholder is bound via session VAR > persisted `CONFIG API` value > endpoint default > error (section 7.3); a literal value is used and validated as-is. ${ENV:NAME} references an operating-system environment variable, resolved at invocation time (section 3.3, EnvVarResolver - namespaced ENV: form, a documented deviation from the spec's original ${NAME} wording to avoid colliding with the pre-existing, unrelated ${var} API-variable templating already used inside a stored endpoint's own definition). The optional trailing TABLE/RAW clause preserves the previous rendering-mode choice, additively, on the new grammar (not present in the original spec text - an explicit product decision, documented in docs/TECHNICAL_CHANGE.md).
Last modified in release 5.2.6.
BroadSQL