There are a few options that you have with the first question you have. Most are not a true API but ways that you can get and write data to Sage 100 from other sources.

• Part of Sage that is either free or an additional module
  • e-Business Web Services
    • Very limited only Sales Order, Customer and Customer contact is really open to this
    • No more development being done with this
    • You have to purchase it
    • Limited Documentation
    • Ports to the server must allow communication
  • SDATA
    • Can be customized and is more open to access additional data more than web services
    • No more development being done and was only on version 1 I believe
    • Limited Documentation and some docs not specific to 100 are on different versions of SDATA
    • Ports to the server must allow communication
  • BOI or Business Object Interface
    • Very powerful and access to just about anything you need
    • Lots of programming to get it to work. Not a simple call and get info
    • Must be local to call the pvxcom object
    • No documentation but there are some reference materials to help
  • Sage 100 Power Apps Connector
    • Need to be connected through Microsoft eco system
    • Limited function but is actively being developed
    • New and not much documentation but more is expected to come as more adopt it
• 3rd Party applications (this isn't a complete list). These are actively being developed
  • In-SYNC
    • This really is syncing data from Sage 100 to your app on the web.
    • Used by many websites and programs to get and write back data.
    • More about it
  • CIMCloud
    • Very much like IN-SYNC but they have an API interface to them that you can use and then they sync back to Sage 100
    • Price is much higher than other options
    • Once data is synced to their platform you can have access through APIs as you would usually expect
    • More about it
  • SDE
    • Can define the resources you need
    • API that is real time using JSON or XML with GET and POST
    • Ports to the server must allow communication
    • More about it

For your second question, Sage 100 can be hosted in the cloud but it is not a cloud based solution.

Hey T-Man, thanks for such an extensive description!

I am looking for ways to integrate our application with Sage100 cloud and it looks like the BOI approach might be useful.

We want to read clients' Account Receivable data, and they won't be paying for any licenses, and any 3rd party clients are also not an option. Would you agree that it might suit better for such a purpose?

I'd appreciate if you could point me to the reference materials you mention.

Cheers

If all you want to do is read data (not write anything back into Sage 100), use ODBC.  BOI has a high learning curve, but ODBC queries are pretty standard (as long as you know where the data lives).

great, thanks Kevin M!

with this approach how is security ensured?

You handle all that yourself.  If you set up a SQL environment with linked server (using ODBC) to Sage data, that should work as a bridge... then you set up secure access to SQL (which should be well documented elsewhere).

I'm sure there are other methods but this is what comes to mind as a potential approach.

You handle all that yourself.  If you set up a SQL environment with linked server (using ODBC) to Sage data, that should work as a bridge... then you set up secure access to SQL (which should be well documented elsewhere).

I'm sure there are other methods but this is what comes to mind as a potential approach.

ScriptBasic's approach to securing connection info is use the ODBC Connect() function with a name as its argument. The associated connection info is stored in the ScriptBasic configuration file which is compiled to binary format.

thanks again!
question on the performace if you will: we are planning to work with great volume of data, are there any recommendations how to avoid any issues with performance, maybe using filtering of queries etc?

If you have a large amount of data, stay away from anything using ADO. 

Deal with that as it comes up, table by table and query by query.  At it's worst, I've used SQL Merge statements to maintain mirror tables in SQL, and if you use SQL Views to start with, making that kind of change later would be be like a black-box change.

If Sage comes through with a SQL Standard edition, I hope the focus will be moving some the business logic to the SQL server as functions and views.