In terms of the 'how' of this, I used a Craft module with console controllers (and a dev environment with a bunch of test orders that covered the wide range of possible orders we offer). This allowed me to develop a robust pushing mechanism easily, with immediate feedback and logging. DEAR offer a reasonably decent REST API (indeed, this was the main reason for using DEAR as a lot of the other inventory type systems have really crappy APIs).

Of course as new business things come along, be they new product categories, or sales/promotional type things, or bundles etc. etc - there is always some significant ongoing work to maintain integrity of the mapping between Commerce (that does only order Capture, although I do use the Commerce order statuses/emails as well by reaching back from DEAR into Commerce)...and DEAR (that does all the order processing/inventory/stock/documents - basically everything but the initial order capture).

All this is a long way of saying - these things are invariably much more complex than they appear on the surface, and typically require more than a no-code approach to be successful & robust over the long term. There is absolutely no way a no-code system would have helped us or been capable of doing even a small fraction of what we do with DEAR. On the other hand, with the relatively simple needs of our Freshdesk integration, I'd imagine a no-code approach would be feasible - if someone did the (substantial) initial work for this.

In terms of the 'how' of this, I used a Craft module with console controllers (and a dev environment with a bunch of test orders that covered the wide range of possible orders we offer). This allowed me to develop a robust pushing mechanism easily, with immediate feedback and logging. DEAR offer a reasonably decent REST API (indeed, this was the main reason for using DEAR - as a lot of the other inventory type systems have really crappy APIs).

Of course as new business things come along, be they new product categories, or sales/promotional type things, or bundles etc. etc. - there is always some significant ongoing work to maintain integrity of the mapping between Commerce (that in our system really only handles the initial order capture, and DEAR (that does all the order processing/inventory/stock/documents)...although I do use the Commerce order statuses/emails as well (so that all our messaging is consistently templated/branded), by reaching back from DEAR into Commerce)...

All this is a very long way of saying - these things are invariably much more complex than they appear on the surface, and typically require more than a no-code approach to be successful & robust over the long term. The fact is there's basically zero chance any two systems will model your products/variants in quite the same way. Certainly, in our case, there is absolutely no way a no-code system would have helped us - or been capable of doing even a small fraction of what we do with DEAR.

On the other hand, with the relatively simple needs of our Freshdesk integration, I'd imagine a no-code approach mightbe feasible - but only if someone did the (substantial) initial work for this. It would likely be a reasonably expensive plugin, and one that needed regular and reliable updating to stay working, as both APIs will inevitably move over time...