Forums - Thread Details
  • State Suggested Answer
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 324 subscribers
  • Views 1194 views
  • Users 0 members are here
Related

Third party integration via API

David Bundock

We have engaged with a third party marketing automation platform.  To get the most from this we would like it and Sugar to talk to each other via an API. 

Do we need to purchase a full Sugar licence to enable this communication or can it be done using a dedicated API user, if so can anyone advise how this is accomplished?

Thanks

David

  • 0

    Sugar UI and API allows to access Sugar business logic on behalf of the authorized user - according to that user license type. Therefore, it's up to you to deside wether interaction should be performed on behalf of the user configuted for integration only, Admin or another named user

    AFAIK, to avoid issues of user concurrent access via different interfaces (UI, API) , developers use platform parameter during user oauth2 authorization via API.

    Do you intend to develop integration from the scratch? 

    Best Regards,
    Dmytro Chupylka

    integroscrm.com
    We make work in Sugar CRM system faster, more convenient and efficient

  • 0

    It is up to you if you want an different user that connects to the api or that you solve it using a different platform and oauth2 keys. Personally I would use a different user. This way if the connection / integration is ended you can simply revoke the credentials of that user. On top of that when the integration creates/updates data in your sugar environment and you are using a known user you don't know that the change was made by that integration or by the user him/her self. 

    As Dmytro asked, are you going to develop the integration yourself? 

  • 0

    Normally we would use a separate user for various reasons during integrations:

    • there is no confusion to users what changes records, especially if the user is clearly named
    • normally integration users have different permissions as regular users (normally integrations act as admin)
    • with the current capabilities, password management is clearer, and there is clear separation also for SSO purposes between integration users and application users
      • especially when leveraging SSO, I am pretty sure that today you would need a non-sso user to complete server to server integrations
    • for 2 way syncs polling based, it allows to easily stop loops based on last modified user on the Sugar side

    --

    Enrico Simonetti

    Sugar veteran (from 2007)

    www.naonis.tech


    Feel free to reach out for consulting regarding:

    • API Integration and Automation Services
    • Sugar Architecture
    • Sugar Performance Optimisation
    • Sugar Consulting, Best Practices and Technical Training
    • AWS and Sugar Technical Help
    • CTO-as-a-service
    • Solutions-as-a-service
    • and more!

    All active SugarCRM certifications

    Actively working remotely with customers based in APAC and in the United States

  • 0

    To expand a little bit on what everyone else said, there are 4 types of users in Sugar:

    - Regular users

    - Admin users

    - Group users

    - Portal API users

    The first two require a Sugar seat license, and will allow access to all records in Sugar (for regular users, depending on the implemented access controls). The second two do not require a Sugar license seat, but come with restrictions: group users cannot log in to Sugar and can only be used to have records assigned to them, while Portal API users can only access the Sugar Portal and does not have access to the full Sugar API. See here for more info: https://support.sugarcrm.com/Knowledge_Base/License/User_Types_and_Sugar_Licenses/

    With respect to whether to use a separate user (along with a separate seat license), I agree with everyone: a separate user is the way to go, for the reasons outlined. 

  • 0

    Thanks everyone for your help, this has really clarified things and following the advice on this thread we will be utilising a separate user for our integrations. I was nervous of using a shared licence, not because of the clashes but more because of the security implications of having to leave it more open than absolutely necessary.  

    Thanks

    David