If you should provide an API for other existent products to interact with, then your choice should be based on the requirements of those products. Comments by TZHX explain all that in detail.
I suppose, however, that it's not your situation. In other words, CRM and ERP systems don't interact with your software: instead, your product interacts with those CRM and ERP systems through the API they expose. Your intention is to simply have an API for future products which could be built around your product, and your question is about that API.
In this case, the answer is rather straightforward. Basically, SOAP's popularity is decreasing, while REST appears very attractive. Aside the REST hype, there are concrete reasons which explain that: SOAP is more bandwidth heavy, especially compared to JSON-based REST, and SOAP has its niche, which is narrowing over time. For instance, in Microsoft's world, SOAP through WCF is an interesting option; however, WCF's future is rather unfortunate.
Providing SOAP may make sense in some situations:
Your product is in a field where everyone uses SOAP on daily basis. If all your competitors provide a SOAP API, you may have one as well.
Your product is addressed to the developers who used SOAP in the past and don't know or care about REST.
The developers who will interact with your product have some powerful tools which make it easy to use SOAP. For instance, in WCF projects, any service which presents itself through WSDL can be imported in Visual Studio, and its client source code will be generated, automatically. And updated automatically as well when the service changes. Very convenient.
In other cases, REST API is largely enough. Note that you can develop both the API and the API clients in mainstream languages, making it easier for other developers to interact with your API. For instance, Amazon does that, and so do Google and Twilio and others.