BroadSQL Download
On this page
Documentation / API Client: overview

Universal API Client

Experimental feature. The Universal API Client is experimental and under observation. Its commands, workflows and configuration model may change significantly in future BroadSQL releases, and long-term compatibility is not guaranteed yet: do not assume that what you configure or script today will work unchanged in a later release.

BroadSQL can import an HTTP API's definition from a Bruno collection and call it directly, reusing the same workbench you already use for databases.

What this is for

Many day-to-day investigations involve both a database and the application/API in front of it. Universal API Client lets you import an existing Bruno collection once, then browse and call its endpoints from BroadSQL: no separate tool, no re-entering URLs, headers, or credentials.

Every commonly used HTTP method is executable: GET, HEAD, POST, PUT, PATCH, and DELETE. The one exception is OPTIONS, which is imported and visible like any other verb but cannot be executed; see Supported HTTP methods and What this release does not do.

An API does not have to come from Bruno at all. CONFIG API (see Configuring APIs with CONFIG API below) is a graphical window for building and maintaining an API entirely by hand: environments, base URLs, variables, authentication, folders, and endpoints, then calling RUN against whatever you configured, exactly as if it had been imported.

Supported HTTP methods

MethodExecution
GETSupported
HEADSupported
POSTSupported
PUTSupported
PATCHSupported
DELETESupported
OPTIONSNot supported

Every method, supported or not, is imported, persisted, and shown by SHOW ENDPOINTS (see Browsing endpoints); only execution is restricted. Attempting to execute OPTIONS (or any other/unrecognized method) is refused before any network request, naming the method: see Executing an unsupported method or body.

How it fits together

Working with an API has three separate stages, each on its own page:

  1. Define the source. Import a Bruno collection or build the API by hand in CONFIG API: its environments, base URLs, variables, authentication and endpoints. See API sources and configuration.
  2. Run requests. Connect to one API and environment with CONNECT API, browse its endpoints, then send requests with RUN. See Running API requests, and Parameters, variables and authentication for how the values in a request are found.
  3. Use the result. Read it as a list, a table or the raw body, copy it, or export it with DUMP API RESULT. See Working with API results.

Examples and troubleshooting shows the three stages together, and the messages you may meet.

IMPORT API BRUNO "C:\bruno\my-api.yml" MYAPI;
CONNECT API MYAPI:Development;
SHOW ENDPOINTS;
RUN /users TABLE;
DUMP API RESULT TO USERS AS CSV;

What this release does not do

  • Execute OPTIONS endpoints, or any other/unrecognized HTTP method (imported and visible, not executable, whether imported or configured by hand in CONFIG API).
  • Execute an endpoint whose request body is configured as form-urlencoded or multipart-form. Both are stored and preserved losslessly, and remain editable in CONFIG API, but cannot be sent yet; only json/text/xml/sparql bodies can be executed. See Request bodies.
  • Provide a field-by-field editor for a structured request body; it remains raw canonical JSON text in CONFIG API.
  • Validate that an interpolated request body is syntactically valid JSON before sending it; the configured text is substituted and sent exactly as it resolves, the same way URL/header substitution already works.
  • Execute anything at all from CONFIG API itself; it is a configuration tool only.
  • Prompt for confirmation before running a POST/PUT/PATCH/DELETE endpoint; running RUN against it is itself the instruction, exactly like every other command.
  • Automatically select, hide, or infer a subset of fields to display for an API result. LIST, the default, always shows the complete response, and TABLE, when chosen explicitly, never drops a field either. See Result display: LIST and TABLE. An explicit, user-chosen field projection (conceptually similar to SQL's SELECT id, name, status) is a possible future direction, not implemented in this release.
  • Run a future CALL-style script statement using an endpoint alias; the alias exists today only as reserved, stable metadata for that future statement.
  • Import a directory-based (multi-file) Bruno project, only a single bundled YAML export.
  • Import Postman collections or OpenAPI/Swagger specifications, or export to either format.
  • Import or run Bruno scripts, pre/post-request automation, assertions, or tests.
  • Relationalize or join an API result against another table server-side; DUMP API RESULT TO ... AS H2 materializes it as a plain, unrelated table with text-only columns, ready for BroadSQL's normal JOIN once exported, but no typing or relationalization happens automatically.
  • Automatically delete something from BroadSQL's catalog because it was removed from a re-imported collection; re-import only ever creates or updates, and the same applies to CONFIG API's own manual editing.
  • Preserve a BroadSQL-assigned endpoint alias through an export followed by import into a different BroadSQL installation (it is never written to the exported file at all).

Found something wrong or unclear on this page? , with the page address.