The Data Hub catalog is like a phonebook for deployed apps, their endpoints, and their contracts. It helps developers of client apps to find out what they can connect to. It helps them understand what version is deployed in test, in acceptance, and in production.
If you make a change to an OData API in Studio Pro you may never deploy this, It might be a mistake that you’ll undo tomorrow. So showing this in the Data Hub Catalog would be misleading to developers of client applications.
This means that you’ll need to deploy your app first before developers can see the updates in Data Hub Catalog. This could be test, acceptance or production as the Data Hub Catalog will tell you exactly what is available in every environment.
The development model that the Data Hub Catalog supports is one that you would expect when working with 3rd party services from for example Google or Slack. When working with these services you don’t know or care what their internal changes are, as long as you know the contract of the APIs you can connect to. The goal is to support autonomous teams building decoupled microservices rather than tightly coupled teams build distributed monoliths.