it depends if you planning to use jBPM in embedded mode or use directly kie workbench. Assuming based on the description more suitable is embedded option.
You're right kie workbench does store all deployments in git repository (system repository) but it does store only identification of the module that is deployed (like GAV of kjar). On the deployment time it is then parsed and produces a DeploymentEvent so others can observe and get relevant data out of it, like list of available processes, forms, etc. Please note that it's done over CDI and if that fits your environment you should use DeploymentService (KmoduleDeploymentService) and then react on the events of deployed units and store them wherever you like. kie workbench uses system git as that is central place for config data and then process definitions itself are only stored in memory and restored on every application start.
Actually we are still planning to use the kie workbench we just want access to the information outside the workbench to trigger workflows - does kie workbench expose an API to retrieve this information? Also the JBPM supports an interface to start processes remote through REST calls - where does the application developer typically get the metadata (such as process id) to make these calls?
so in that case using REST api would be the way to go. I believe deployments resource was added just few days ago so you might want to look at what's available in master and see if that fits your needs or there is still something missing and if so, file a jira.
For the remote api it would be similar as you would do it over local api, get processes from kbase. Although it might be a good idea to expose that as well over RuntimeManager api too. Again, would be great to get a jira for this