BroadSQL BroadSQL Downloads
Articles / What is new in BroadSQL 5.3.0

What is new in BroadSQL 5.3.0

September 20, 2026

#release #api #scripting #completion #upgrade

BroadSQL 5.3.0 reshapes three things you touch every day: how you call an HTTP API, how you type commands, and how you keep and run your Scripts. This article walks through what changed, what each change gives you, and the handful of places where an existing setup needs attention.

Some releases add a command or two. This one is different. BroadSQL 5.3.0 changes the shape of three working areas, and a few of those changes are breaking. Nothing here needs a special upgrade tool, but a few habits and one type of file need a second look, and they are listed near the end so you can check them against your own setup.

The three areas are easy to name. The Universal API Client now works the way you would expect a command-line client to work: you connect to an API environment once, then run URLs against it. Interactive completion now knows about your own connections, environments, groups, scripts and API endpoints. And BroadSQL now has one kind of runnable file, the Script, and one place to keep reusable ones, the Scripts Library.

The API client itself is not new in 5.3.0. Its foundation, including Bruno import, CONFIG API and execution of GET, HEAD, POST, PUT, PATCH and DELETE, arrived in 5.2.4. If you read the earlier article on configured operations, SQL and automation, you have the background. What 5.3.0 does is change how you run a request and how you inspect what comes back. That is why the API section below spends time on behavior and not only on features.

The full list is in the release notes. This article is the version you can read in one sitting: what is new, and what it brings you.

BroadSQL is no longer only about databases

A lot of investigations do not stay inside one database. A customer reports a wrong status. You check what the service returns, then what the table holds, then perhaps what the same service returns in another environment. Before, that meant a database client in one window and an HTTP tool in another, with a copy and paste step in between.

The Universal API Client puts the HTTP half of that investigation in the same prompt as the SQL half. You bring an API into BroadSQL in one of two ways. You can import a Bruno collection, exported as a single bundled OpenCollection YAML file, with IMPORT API BRUNO. Or you can build the API by hand in CONFIG API, a Windows window for environments, base URLs, variables, authentication, folders and endpoints. Either way, the result is the same catalog, and everything below works on it.

Once an API is in the catalog, these are the things you can do from the BroadSQL prompt:

The client executes GET, HEAD, POST, PUT, PATCH and DELETE. OPTIONS endpoints are imported and visible, but BroadSQL refuses to execute them, and it says so before any request leaves your machine. The same applies to endpoints whose body is a form or multipart form: they are stored and editable, but not yet sendable. Only JSON, text, XML and SPARQL bodies go out.

BroadSQL does not ask for confirmation before a POST, PUT, PATCH or DELETE. Typing the command is the instruction, as with every other BroadSQL command. Point it at the environment you mean.

Working with an API in the same session as SQL

The central idea of the client is the API session. You choose an API and an environment once:

CONNECT API MYAPI:Development;

From then on, the prompt shows the API context next to the database one, for example $CDF [API MYAPI:Development]>. That matters because the API session and the database connection are independent. CONNECT API does not close your database connection, and connecting to a database does not clear your API context. DISCONNECT API removes only the API part.

In practice, you can do this without switching anything:

CONNECT API DESK:PROD;
RUN /api/rest/emails/v1/ping?key=DESK;
SELECT COUNT(*) FROM CUSTOMER;
PULL API RESULT TO PING_RESULT AS CSV;
DISCONNECT API;

The request goes to the service. The query goes to the database. The saved result comes from the service response. Nothing in the session had to be closed and reopened.

Environments are what keep this safe to repeat. Each environment of an API has its own base URL and its own variables, so the same endpoint resolves to a different server depending on the environment you connected to. Switching from Development to Production is a new CONNECT API, not a new set of requests to maintain. Three commands help you see what you have. SHOW ALL APIS lists the catalog, SHOW API ENVIRONMENTS lists an API's environments, and the new SHOW API ENVIRONMENT shows one environment. The first two now print bordered tables.

If an API or an environment has been deactivated in CONFIG API, BroadSQL refuses to run against it and names it as inactive, so you do not get a confusing "not found". An existing session does not silently keep working. You disconnect and reconnect after reactivating.

Finding the endpoint you want

An imported collection can hold dozens or hundreds of endpoints. The useful question is rarely "how do I call this?" but "which one do I need?" 5.3.0 gives you three ways to answer it without leaving the prompt.

SHOW ENDPOINTS lists the endpoints of the connected API as a compact table with ID, verb, folder, name and alias. You can narrow it down with a verb, a keyword, or both:

SHOW ENDPOINTS VERB POST MATCH customer;
SHOW ENDPOINTS API MYAPI VERB GET MATCH search;

The keyword search covers the folder path, the name and the alias together, and it is not case sensitive. A search with no results is an empty list, not an error. Notice the second example: API MYAPI lets you list the endpoints of an API without any session at all, which is useful when you are just looking around.

When you have found a candidate, SHOW ENDPOINT shows it in full. You give it a numeric ID, an alias or a name. It shows the method, the folder, the composed URL, the query and path parameters, the headers, the body and a summary of the authentication. If a name matches more than one endpoint, BroadSQL prints the candidates and asks you to use an ID or alias. It does not pick one for you.

The third tool answers a different question: how do I call this? SYNTAX takes an endpoint reference and prints its URL shape, its required and optional parameters with their allowed values, and examples of the RUN command. It reads all of that from the endpoint's own stored configuration, so it cannot drift away from what RUN actually accepts.

The gain is simple. You no longer need the source collection open beside BroadSQL to remember what a service exposes. You search, look, and copy the syntax from the same window where you will run it.

RUN takes a URL

This is the change that existing users will notice first, so it is worth being clear about it. In 5.3.0, RUN takes a URL:

RUN [HTTP_METHOD] <url> [TABLE|RAW];

The method is optional and defaults to GET. The API and environment come from CONNECT API, and only from there. There is no per-call API or environment clause. To run against Production for one call, you connect to Production first.

CONNECT API MYAPI:Development;
RUN /users/42;
RUN DELETE /users/42;

Behind the scenes, BroadSQL matches the URL against the connected API's stored endpoints by method and path shape. So /users/42 finds an endpoint stored as ${baseUrl}/users/:id, and that endpoint supplies the authentication, the headers and the body. If a URL could match both a literal segment and a placeholder, BroadSQL takes the most specific endpoint. If nothing matches, you get an error that points you at SHOW ENDPOINTS.

This has a practical consequence you will like. What you type is what is sent. The line in your history shows the method and the path, not a numeric ID you have to look up again. And the query parameters written in the URL are the ones that are sent.

What about the shortcut of running an endpoint by ID or alias? It is gone from RUN, and RUN CUST; is refused with a hint. The alias and the ID are now discovery handles. SHOW ENDPOINT, SYNTAX and HELP accept them, and, as you will see in the completion section, pressing TAB after RUN expands them into the real URL. That keeps the convenience where you type, and keeps the command itself readable afterward.

If you wrote scripts against the earlier development syntax, this is one to review. RUN <id-or-alias> and the API and ENV clauses no longer exist. SHOW API ENDPOINTS was removed as well; use SHOW ENDPOINTS API <apiId>. EXECUTE API ENDPOINT is no longer a documented command.

Parameters, variables and headers

A URL you type is rarely constant. You want the same request with another customer ID, or another country code. 5.3.0 gives you several placeholder forms, each with one job.

A :name placeholder in the URL, such as /customer/:id, is resolved fresh for that call. BroadSQL looks for a value in a fixed order: a session variable, then the API environment's variables, then the value stored on the endpoint, then the endpoint's default. If none of them provides one, the call stops before any request is made and tells you which value is missing. The order is documented, so you can predict which value wins.

The session variable comes from VAR:

VAR ID=123;
RUN /api/customer/:id;
VAR NAME="John Doe";

A plain VAR lasts for the session and touches no stored data. Add PERSIST, as in VAR ID=123 PERSIST;, and the value is written to the connected API environment's own variables instead. Those are the same variables the API Environments tab of CONFIG API edits. That is a deliberate configuration change, so it needs an active API session, and it clears a session variable of the same name so nothing stale hides the new value.

Operating system variables use a different form, ${ENV:NAME}. It reads the variable when the command runs, and an undefined one is an error, not an empty string. That is helpful when a script should take a customer ID from the outside:

RUN /api/customer/${ENV:CUSTOMER_ID};

Then there are the variables stored with the API. They are written ${name}, and the Bruno form {{name}} is accepted too, so a collection keeps working when you import it or export it back. They resolve from the broadest scope to the narrowest: the API, then the environment, then the folders, then the endpoint. The most specific definition wins, so a shared endpoint picks up the values of whichever environment you connected to. baseUrl is just an ordinary environment variable, set as the Base URL field in CONFIG API. Variable names are case sensitive, and a missing one stops the request with its name.

Headers follow the same idea. Each API, folder and endpoint can define them, and the more specific level overrides the broader one. The practical benefit is that a required header, such as an Accept type, is configured once on the API and does not need to be repeated on each call.

Secrets are handled with care. A value marked secret is masked in every table BroadSQL prints and is never echoed by RUN, SHOW ENDPOINT or CONNECT API. The request body is never echoed either. Masking affects display only; the value is still sent correctly.

Authentication and the network

The client supports the authentication types most services use: none, HTTP Basic, a static Bearer token, an API key in a header or a query parameter, and OAuth2 Client Credentials. For OAuth2, BroadSQL fetches the access token itself, keeps it in memory and refreshes it before it expires. It is never written to disk.

You set authentication on the whole API, on a folder, or on a single endpoint. A more specific level overrides a broader one. Inherit means "use the level above", and None means "no authentication here, whatever the level above says". The distinction matters for the one endpoint that must be called without credentials, and it survives a round trip through Bruno export.

A credential can reference an environment variable, which is the usual Bruno pattern. Because the variable resolves against the environment you connected to, switching from Development to Production also switches the credential. There is no separate step to remember.

Schemes that a Bruno collection may contain but that BroadSQL cannot execute, such as Digest, NTLM, OAuth1, AWS Signature and the OAuth2 Authorization Code and Password grants, are imported and kept, but running such an endpoint is refused with the scheme named. BroadSQL does not send it without authentication and hope for the best.

New in 5.3.0 is proxy support for organizations that require one. Three settings modes exist for apiproxymode in the application settings: NONE, SYSTEM and MANUAL. The proxy applies to API execution only, not to database connections. With MANUAL you give the host and port, and the proxy user name and password can be read from operating system variables with the ${ENV:NAME} form, so they need not live in the file. If you work behind a corporate proxy, this is the setting that decides whether the API client is usable at all.

Reading the response

An API response is not a SQL result. There is no SELECT id, name that narrows what comes back, and a response may have many fields or very wide values. 5.3.0 therefore changes the default display to a complete list that keeps the structure of the response. Every field is shown, nested objects are indented under their field name, and arrays appear as numbered entries. BroadSQL never picks the fields it considers important, and it never truncates a long value.

HTTP 200
Duration: 98 ms
Content-Type: application/json

[1]
  id   : 1
  name : Alice

[2]
  id   : 2
  name : Bob

Two trailing keywords change that. TABLE shows a table when the response has a table shape: an array of objects, a single object, an empty array or an array of plain values. Nested values stay as compact JSON inside a cell. Any other shape falls back to pretty-printed JSON. RAW always shows the pretty-printed JSON or the raw text. None of the three modes discards the response body, and none of them removes a field.

RUN /users TABLE;
RUN /users RAW;

The list view is a good default when you are reading a single record or an unfamiliar response. The table view is better when you are scanning many similar rows. You choose per call, and you do not need to change any setting.

HTTP errors are treated as results, not as failures of the tool. A 404, 401 or 500 is displayed exactly like a 200, with its status and body, because the status and the body are what you came to see. A 204 with no body is shown cleanly. A network failure, such as a refused connection, a DNS problem or a timeout, is reported separately, since there is no status to show. A response that cannot safely be shown as text is summarized by size and content type instead of being dumped as bytes. The distinction is helpful during diagnosis. It tells you whether the service answered with an error, or whether you never reached it.

Reusing an API result

A response you can only read on screen is half useful. 5.3.0 gives you two ways to take it elsewhere, and both work from whatever you just ran.

COPY RESULT copies the most recent successful result to the clipboard as tab-separated text, ready to paste into Excel or Calc. That result may come from a SQL query or from RUN, whichever ran last. A statement or API call that fails never replaces it, so a typo after a good query does not cost you the data you wanted to copy.

RUN /users;
COPY RESULT;

PULL API RESULT, described in the Export guide, takes the same captured response and writes it somewhere durable: a local H2 table, an XLSX or ODS spreadsheet tab, or a flat file such as CSV. It does not call the endpoint again, which matters for a write request or for a service whose data changes between calls.

RUN /users;
PULL API RESULT TO WORKCOPY.USERS AS H2;
SELECT * FROM WORKCOPY.USERS;

Two limits are worth knowing. Every column of an API result lands as text, since the response was never typed to begin with, and you apply the conversions you need in SQL. And MODE APPEND is not supported for this source; the default is a full overwrite. The captured data is always the tabular shape described above, independent of the display mode you used on screen.

The combination is where the client earns its place in BroadSQL. You can preserve what a service returned at a certain time, load it into H2, and join it to database tables with ordinary SQL. The snapshot is local data, not a live view over the service, so you decide when to capture another one.

A smoother CONFIG API window

CONFIG API is a configuration tool, not an execution window, and 5.3.0 tightens how it behaves. It now has one Save, Ctrl+S, in place of several per-object Save buttons. The window title shows an asterisk when something is really unsaved, and moving between an API, an environment and an endpoint asks whether to save, discard or cancel if you would leave changes behind. Opening the window and clicking around without editing never prompts.

The endpoint editor keeps the URL and the query parameter grid in step in both directions. Disabling a parameter removes it from the displayed URL without deleting its definition. Editing the URL to remove a parameter disables its row instead of deleting it. So a slip while editing does not lose a value you configured. A disabled parameter is also never resolved or sent, which means that an unset variable behind it no longer blocks execution. A live search field above the endpoint tree filters by ID, name, alias, folder, verb or URL as you type. File > Exit closes the window.

These are small individually. Together they answer a question that any configuration window must answer well: is what I see the thing that will be saved, and is the thing that will be saved the thing that will run?

Faster command-line work with TAB completion

The other large change is at the keyboard. When activatejline=ON is set in BroadSQL.ini, BroadSQL uses JLine for the interactive prompt. The setting is off by default, and it never changes what a command does or accepts. It only changes editing and completion. If JLine cannot start for any reason, BroadSQL prints one warning and falls back to the standard console. The application settings page describes the keys, and the Getting started guide describes the completion behavior.

With it on, TAB completes BroadSQL commands and subcommands and SQL keywords. Once you are connected, it completes schema, table, view and column names, including in a statement that runs over several lines. When there is one match, it completes directly. When there are several, a menu opens: TAB moves forward, Shift-TAB moves back, and typing more characters narrows the choice. Nothing is picked for you.

That part is useful, but the more interesting part of 5.3.0 is that completion now knows your own names. You no longer have to remember the exact ID of a connection, or retype it in full. TAB completes, by case-insensitive prefix:

The name inserted is always the stored one, so CONNECT war<TAB> can become CONNECT WAREHOUSE_DEV, with the original capitalization. If nothing matches, the line stays as you typed it. The candidates are read from the same places the commands use, so a connection or script you created a moment ago is offered right away. A script path that contains a space is inserted in quotes, the way BroadSQL expects it.

The practical effect is on how you work across many connections. If you manage dozens of them, the habit of typing CONNECT and a few letters is faster and less error-prone than recalling a full name, and you are less likely to connect to the wrong one because two names look alike. You see the list before you commit.

API work gets the same treatment. After RUN, TAB offers the endpoints of the connected API by name, alias or ID, and expanding one inserts its real URL. This is the counterpart of the URL-based RUN: you type RUN get<TAB>, pick an endpoint, and end up with a full, readable command. After the ? in a URL, TAB completes query parameter names and their allowed values. After ${ENV: it completes the names of operating system variables. A bug that treated a half-typed word as an already given HTTP method, and therefore hid endpoints from the list, is fixed.

Two smaller interactive changes belong here. Command history is now saved per operating system user and reloaded the next time BroadSQL starts, so Up, Down and Ctrl-R reach back beyond the current session. A password you type is never echoed and never recorded, in memory or on disk. And a console line that holds several statements ending in ; now runs them in order and stops at the first one that fails, which is the safer behavior when a later statement depends on an earlier one.

One kind of file: the Script

The third change is the largest one for anyone who keeps a folder of saved SQL. Before 5.3.0, BroadSQL had two catalogs that overlapped: a SQL library for saved queries and a separate scripts catalog for files that mix SQL and commands. In 5.3.0 there is one concept, the Script: a text file holding SQL statements, BroadSQL commands, or both. A file with a single SELECT is a Script with one statement. There is no second kind for "a saved query".

The Scripts Library is the default place to keep reusable ones. It is a folder, scripts/ by default, set with the ScriptsLibrary key in BroadSQL.ini. It is a place, not a different type of file. A Script inside the library and a Script anywhere else behave identically when you run them.

The file extension carries no meaning. customer.bsql, customer.sql, customer.txt and a file named just customer are all Scripts if they are text and hold valid input. New Scripts created in the editor default to .bsql, since a Script may contain commands as well as SQL, but .sql remains fully supported.

You run a Script with @, now documented and visible in HELP, or with LIB RUN. Both share one execution pipeline and one parameter contract, and so does a run started from the editor. What a reference means depends only on how it is written:

@cleanup.bsql                  Scripts Library root
@maintenance/cleanup.bsql      a subfolder of the library
@./helper.bsql                 working directory, or the running Script's folder
@C:\temp\foo.bsql              any explicit path
@"C:\My Scripts\foo.bsql" value1 "value 2"

The @./ form deserves a note. Typed at the prompt, it is relative to the working directory. Written inside another Script, it is relative to the folder of the Script that is running, so you can move a folder of related Scripts as a bundle and the internal calls still work. A plain reference such as @common/util.bsql, on the other hand, always starts at the library root, even when it appears inside a Script.

Parameters use %1 to %9, given after the reference: @customers.bsql CH 800. Several parameter bugs were fixed in this area. %10 is no longer read as %1 followed by a zero, a value that itself looks like %2 is inserted as written, and the placeholders now also work in INSERT, UPDATE and DELETE statements.

Scripts can call other Scripts, with guard rails. A Script that calls itself, directly or through others, is refused right away and BroadSQL prints the chain of Scripts involved. Nesting is limited to 32 levels. After each called Script, the execution context is restored, so the caller carries on. A nested call that used to run twice no longer does.

Some quieter improvements matter when a Script is long. A quote or block comment that is never closed now fails the whole Script up front, with the line and column, instead of quietly running only part of the file. An indented or trailing line comment no longer discards every statement after it. And a text file saved in a legacy encoding is read with the Java default character set instead of failing. A file that is not text, meaning its start holds a NUL byte or mostly control characters, is not listed, opened or run.

Managing the library

A folder of scripts needs a way to browse, search and clean up. The LIB family covers it, and LIB LIST now always includes subfolders, so the old ListSubfolders setting is gone. Scripts appear under their library path, such as maintenance/cleanup.bsql.

The header tags are worth a word. A Script can begin with lines such as -- @description: Monthly revenue by country or -- @environment: PROD. They describe a Script and help the list view scope itself. They are safeguards, not access control: when a Script starts, its tags are compared with the current connection, a mismatch prints a warning, and the Script runs anyway. And they are never a way to find a Script by anything other than a search.

Editing goes through the BroadSQL Editor. LIB EDIT and EDIT open it. The library appears there as a folder tree, with New Folder alongside New, Rename, Duplicate and Delete. The editor opens any text file whatever its extension. It keeps the encoding a file was read in when it saves, and it refuses to save if the text could not be represented in that encoding, which protects an old file from silent damage. Opening the editor needs no database connection; only running a Script from it does.

One editor behavior is easy to overlook, and it is a good example of a decision made for safety. When you use Format, BroadSQL does not send the whole file to the SQL formatter. A Script may hold commands, and a formatter that only understands SQL could damage them. So BroadSQL splits the text into statements using the same rules that execution uses, reformats a statement only if it is SQL that the formatter accepts, and leaves every BroadSQL command exactly as written, byte for byte. If a quote is never closed, it declines to format at all and says where.

The editor also runs a Script. It always runs what is saved on disk, and if the tab has unsaved changes, it asks you to save first. There is no option to run the in-memory buffer, so it cannot run an older version than the one you see. It also keeps a revision history, and the editor guide describes the History window and the side-by-side comparison. It notices when a file has changed outside BroadSQL and asks before overwriting.

Two smaller editor fixes are worth mentioning because they were irritating. Opening a saved Script no longer marks it as having unsaved changes, and closing the editor no longer leaves tabs that BroadSQL asks about again when you type EXIT.

Deleting without regret

Deleting a Script is where a library either earns trust or loses it. In 5.3.0 there is a single model for it. LIB DEL asks for a y or n, then moves the Script into the library's archives/ folder. It does not delete it. The editor's Delete does exactly the same, and its Recently Deleted window lists the same archive. Nothing is purged automatically.

To bring a Script back, use LIB UNDO for the most recently archived one, or LIB RESTORE with the exact path the Script had. Both refuse, rather than overwrite, if a Script already exists at that path. LIB LIST ARCHIVES shows what is archived.

The revision history follows the archive. Restoring a Script continues its history, while a new file created at the same path after a deletion starts a new one. That is the behavior you would want: a restored Script is the same Script, and a fresh file is not pretending to be an old one.

Movement between systems

You will notice that this article says little about LOAD, and that is deliberate. Data import with LOAD was reworked in 5.2.4, with previews, parameter-bound inserts and a rollback if any row fails. That is described in the Import guide. In 5.3.0, LOAD itself is unchanged. What changed is where it runs: from a Script started with @ or LIB RUN, a plain LOAD refuses to write, and you use PREVIEW to validate or EXECUTE to authorize the insert.

The 5.3.0 story for moving data is about the API client. A response is no longer something you can only look at. It can go to the clipboard, to a spreadsheet, to a file, or into a local H2 table beside your other data, all through commands you already knew. That is the fair summary of "data movement" in this release. It extends what BroadSQL can treat as a source of rows.

Smaller changes worth knowing

A few items do not fit a theme but are worth a mention because they remove friction.

Individually these are unremarkable. Collectively they mean fewer surprises in a session that mixes the editor, the configuration window and the prompt.

What you need to check before upgrading

Several changes in 5.3.0 are breaking. None is complicated, but each is a place where an old habit or file will stop working, so here they are in plain terms.

The old SCRIPT commands are gone

The SCRIPT command family, meaning SCRIPT RUN, LIST, SHOW, FIND, EDIT, EDITOR, DEL, RESTORE, UNDO and LINT, together with their SC aliases, has been removed. Run a Script with @name or LIB RUN name, and manage Scripts with the LIB commands. The settings SqlLib, Scripts and ListSubfolders no longer exist. They are ignored, with no fallback and no migration. Set ScriptsLibrary instead, and move the Scripts you want to keep from the former folders into it yourself. BroadSQL does not move, merge or delete your files.

References are exact

A reference now means exactly the path you write. LIB RUN foo no longer finds foo.sql. A bare file name no longer finds a Script in a subfolder. The @alias header line no longer finds anything, and an old one is an ordinary comment. Use the exact path, for example LIB RUN maintenance/foo.sql. LIB RUN also refuses paths outside the library, so for a file elsewhere use @ with an explicit path. Nothing is searched, and that is the point: the name you type is the file that runs.

Two smaller notes on the editor. It no longer shows JavaScript files. Edit .js files in any external editor; the JS commands and the JsScripts folder are unchanged. And editor history recorded under the previous library locations is not carried over, and Scripts deleted in the editor before this release do not appear in Recently Deleted.

RUN takes a URL

As described earlier, RUN takes a URL and not an endpoint reference. CONNECT API <api>:<environment>; comes first, then RUN with the URL. If you see RUN CUST; in an older Script, replace it with the real URL, and use TAB after RUN or SYNTAX CUST; to find it. Alias and ID handling stays in SHOW ENDPOINT, SYNTAX and completion.

Java packages moved

BroadSQL's Java packages moved from com.projectsontracks to com.upandcoding.broadsql, with no compatibility layer. This matters only if you wrote an extension. An extension JAR built against an earlier release must have its imports changed and be rebuilt against 5.3. The Extending BroadSQL guide shows the current import lines. If you have never written an extension, this change does not touch you.

What 5.3.0 changes in day-to-day use

Put the pieces together, and the release has a coherent direction. BroadSQL used to be a place where you ran SQL and, on the side, some commands. In 5.3.0, it is closer to a place where you run things: queries, requests and saved procedures, in whatever mix an investigation needs.

For the API work, the change is that a service is no longer a foreign object. You choose an environment, find an endpoint, type its URL, read the whole response, and keep the parts you need, without leaving the prompt or closing your database connection. For the keyboard, it is that BroadSQL now knows the names you have defined and finishes them for you. For Scripts, it is that there is one concept to learn, one folder to look in, and one rule for what a reference means.

The costs are real too. The removals need a small cleanup pass over old Scripts and settings, and extension authors have a rebuild. If you use the API client heavily, the move to URL-based RUN will touch every saved request. None of it is large, and the release notes list each item.

A reasonable order for an existing user is this. Read the upgrade section of the release notes and move your Scripts into the ScriptsLibrary folder. Turn on activatejline if you have not, and try TAB after CONNECT and after @. Then, if you use APIs, run SHOW ENDPOINTS against one of yours, pick an endpoint with TAB after RUN, and look at the list view of the response. Ten minutes of that will show you more than any summary can.

The full detail is in the Universal API Client guide, the Scripts and Scripts Library guide and the BroadSQL Editor guide.