I completely agree!
The reason why people go with SugarCRM is because of its open source nature and cost effectiveness. If they are required to pay for additional license every time they integrate with a 3rd party application, then that just beats the purpose of being open source wouldn't it?
I strongly agree with this idea. I suggest to add that as an option to the user type field (regular / Admin), so it is possible to check access right as regular user during development and change it to API user for production.
This should not be to hard, as Sugar Enterprise has a possibility to create portal api users, but those can only access the portal moduels (tickets, bugs, knowledge).
Also, more than one API user is needed, because if you for example create opportunities from different external sources through the API, the creating user is important.
This is already possible since 2009 on Sugar Enterprise and Professional v5.5
Are you referring to Portal API Users? Those serve a different purpose as far as I understand, and are only for Enterprise/Ultimate, not Pro.
It can be enabled for Pro version too.
blakerobertson.com - devlog - Creating an "API Only" User in SugarCRM
the problem with this option is that the created "Portal API User" cannot access all the modules in SugarCRM. It is limited to the modules that are needed for Portal access (Tickets, bugs, Knowledge base and contacts (for managing the customers' own data)). You cannot create new opportunities or calls through those users.
I'm going by official statements by Sugar, like here posted only 6 days ago:
When Choosing a CRM, Beware of Hidden Costs « SugarCRM Corporate BlogSee last section headed; "What About SugarCRM" this piece of text;
Organizations can customize and build on the Sugar platform without hidden fees or forced upgrades to more costly editions. Additionally, users can make any number of integrations without additional charges or fees.
I think the chapter about integrations and building on the platform talks more about customizing SugarCRM itself than connecting external systems.There are no "hidden" fees in the sense of that you know what every seperate API user costs and you do not need to upgrade to get API access.
Also, the Master Subscription Agreement (MSA) of the commercial versions prevent you from tinkering with core components that would allow you to circumvent the licensing functionality (like heartbeat, portal functionality, license checking and such things) - the files for those even contain warnings not to tinker with them.
Some questions for the group, as this request would fall under my team's purview...
Would one be enough? We need to be cognizant of the obvious risks of somebody creating 500 API-only users and scamming our licenses... especially since with Sugar7's Sidecar framework, most of the application is actually powered primarily through API requests now. Does the group have any recommends as to how we'd differentiate "real" API-style requests and syncing vs. regular application usage? In a safe way? I've taken down the Enhancement filed by Jason, but I'd love to hear more from this group before I discuss with the technical crowd at Sugar.
In my current world, one would be enough so one really simple solution is to give everyone 1 free license with the proviso that the additional one is for the API user, and go on good faith accepting the potential risk that they might use it on the interface too; or just give it away free without provisos and let the administrator choose how to use it.
If people need more than one API user and you wanted to be generous, you could, say, give 1 free license with the first 10, then another free for every additional 100 licenses purchased. Or something like that. So buy 10, get 11. Buy 110 get 112. With the same provisos as above.
That is a great suggestion Francesca Shiekh!
I think this is the way it could work, by tying those users to licenses bought. The quota is something to discuss (I would like a number like "one API license for everx 25 user licenses").
Julian Ostrow: to prevent abuse of the API licenses, is it possible to create a new user type "API user" (contrary to Admin user and Regular user) who is not able to login to the system? That way, no one could use the API users for regular logins to the WebGUI. This also gives a great possibility to troubleshoot an API users access rights by temporarily changing him to regular and login with that user to check directly.
Would you care to reply to my post referring to the 'official' stance by Sugar please?
It is especially important as these previous statements are public and all our customers have seen them, therefore confused when we say they need an extra license for each API integration.
IMO and based on real use cases and trends, one 'free' user license would not be enough.
If companies use CRM 'correctly', then they would also need to at least connect to a professional email marketing system, financial system, and Social Apps.
We must also not forget the IoT is very much a reality, so more connections are being made between systems and 'Things'.
I believe there are also a potential security risk if 'user' licenses are used instead of API only users.
Regarding your justified concern; "differentiate "real" API-style requests and syncing vs. regular application usage"
I'd be surprised if some clever Sugar developers couldn't find a good technical solution to this.
I'd also like to see the API user have an option to disable creation of Activity Stream, Subscription and Favorite records for the API user. If we have a very large initial data migration or ongoing integration, it can fill up the database tables with several gigs of useless data. We had one database with 40GB in the activities and activities_users tables.
you can truncate those tables after inital import or disable activity stream until the system is live.
See my idea about a cleaning job for activity stream also:
Implement cleanup method for Activity Stream
Truncating only works if there is no other data in the tables you want to keep. It is possible to delete data for a single user, but trying to delete one user's data from a 40GB table has been an issue for me. I'd have to limit the queries and continually run them over and over. We did build a schedule that deletes records older than a certain date. I suppose we could build a scheduler that deletes the data for a specific user.
Completely Agree, Also that user must not be able to login to CRM, only API access must be allowed.
Retrieving data ...