People ask when we have such a great-looking GUI for the Hub, why did we choose to create a CLI for parsing, testing, and pushing the assets into the Hub?
The primary reason is automation. 
First let’s backup and explain why the CLI is needed.
It has a repository where you store existing assets. Users interact with the repository through a GUI used for creating services.
But the way to get assets into the repository is through a powerful CLI, command line interface. We built the design interface between the legacy system and the repository as a CLI to support automation. The CLI has other functionality as well including the generation of services and testing of the integration to the legacy system.
The fact is many companies want to build an API Factory.
To do so they need to parse and bring whole sets of legacy assets into the Hub. CLIs are easily scriptable since and work well in batch mode. You can traverse whole directories including their sub-directories quickly and easily to get what is needed.
Plus this scripting makes it easy to be built into automation tools like Jenkins. Once added to Jenkins, the assets can easily be tested at whatever frequency is needed and even reparsed and regenerated. The CLI supports a complete DevOps flow.
In addition the CLI is the only part of the Hub that needs to be installed locally. This simplifies the entire evaluation process. The goal is for any platform to include the best tools needed for each job that needs to get done. The CLI and other components of the Hub are explained at this page on our website.
We’d love to give you a demo.
Please leave us your details and we'll be in touch shortly