Reference · built on requestConnectorCRM & sales

Sugar Sell

Accounts, contacts, leads, and opportunities from Sugar Sell through the Sugar REST API and web logic hooks.

Request accessPricing ↗

About

Sugar Sell is SugarCRM's sales product. Every module is reachable through one REST API at https://<site_url>/rest/v<version>/, where the same paths serve Accounts, Contacts, Leads, Opportunities, Calls, Meetings, Tasks, and Notes. Filtering, related-record links, audit history, and a /bulk call that runs several requests in one query are part of the API. Web logic hooks post record data to a URL you set when a record is saved, deleted, or linked.

An operator on Fibric reads opportunities with their accounts and proposes a note, a task, or a field change. You approve, Sugar receives one request, and the record of the change carries the reason and the way back.

This is a reference listing. It documents what Fibric would read from Sugar Sell and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Accounts, the hub record that Contacts, Meetings, Cases, and Opportunities relate to
  • Any module's records through GET /<module>/filter, using $equals, $in, $gt, $contains, $owner, and other operators
  • Related records through GET /<module>/:record/link/:link_name
  • Field-level change history through GET /<module>/:record/audit
  • Web logic hook posts on after_save, after_delete, after_relationship_add, and after_relationship_delete, carrying the record data and an isUpdate flag

Proposed actions

  • Target capability: propose a new record through POST /<module>, for example a Tasks or Notes record tied to an opportunity
  • Target capability: propose updating fields on a record through PUT /<module>/:record
  • Target capability: propose a batch of changes sent as one POST /bulk call

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Remind an owner before a renewal window closes

    Filter open opportunities whose close date falls inside your renewal window, read the account's contacts through the link endpoint, and propose one reminder task per account.

    With Renewal Reminder

  • Find the pipeline that stopped moving

    Compare each open opportunity's audit history against your stale threshold and propose a follow-up task or a stage review for the owner.

    With Stale Pipeline

  • Pass a won deal to delivery

    On an after_save hook where the sales stage becomes won, read the account, contacts, and notes, and propose the handoff record for the delivery owner.

    With Deal Handoff

Requirements

  • A Sugar Sell instance and a user account for the integration, with client_id sugar unless a custom OAuth client is configured
  • A registered platform value other than base, mobile, or portal, so API sessions do not collide with a user's browser session
  • Admin access to Admin > Web Logic Hooks for change notifications
  • A running cron on the Sugar instance, since web logic hooks are posted from the job queue when cron runs
Authentication
OAuth 2.0 at POST /rest/<version>/oauth2/token with the password grant and a refresh_token grant; access tokens last 3600 seconds, refresh tokens 1209600, and each integration passes its own platform value.

Limits

  • Web logic hooks fire when cron runs, not at the moment of the event, and the documentation lists no retry policy
  • GET /<module>/filter returns 20 records by default and pages with offset; requested field lists always include id and date_modified
  • The Cases module is not available in Sugar Sell Standard or Essentials
  • Custom platform values must be registered before the token request accepts them

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Sugar Sell ↗

Questions and answers

How do I authenticate against the Sugar REST API?
POST to /rest/<version>/oauth2/token with grant_type password, client_id sugar, an empty client_secret, the username and password, and a platform value. The response carries an access_token good for 3600 seconds and a refresh_token good for 1209600 seconds.
Does Sugar Sell push changes to external systems?
Yes, through web logic hooks set up under Admin > Web Logic Hooks. Triggers include after_save, after_delete, after_relationship_add, and after_relationship_delete. Sugar queues each hook as a job and posts the JSON when cron runs, so delivery follows the cron schedule.
Which Sugar Sell editions include Cases?
The Cases module is not available in Sugar Sell Standard or Essentials. Accounts, Contacts, Leads, and Opportunities are the modules this listing reads; a Cases feed needs an edition that includes the module.
Ask about Sugar Sell

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Sugar Sell through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy