REST API

Overview

v10 - v11.23 API documentation.

What Is REST?

REST stands for 'Representational State Transfer'. As of 7.x, REST is a core component of Sugar that defines how all information is exchanged within the application. The v10+ API is separate from the v1 - v4_1 REST APIs in that it has been rebuilt with the latest REST standards. Most functionality in the system, whether fetching or posting data, is interacting with the API in some way.

Getting Started

How to Access the REST Service

The base endpoint for the REST service can be found at https://<site_url>/rest/v{version}/.

Note: version refers to the version of the API you are accessing.

For your reference, the help documentation for all versioned endpoints can be found by navigating to https://<site_url>/rest/v{version}/help. Once you have identified your instance's base endpoint, we can begin by authenticating.

Authentication

Sugar uses two-legged OAuth2 for authentication. You simply need to do a POST to /rest/<version>/oauth2/token with the following parameters:

grant_type	String	Type of request. Available grant types are "password" and "refresh_token".
client_id	String	The client_id of "sugar" will automatically create an OAuth Key in the system and can be used for "password" authentication. The client_id of "support_portal" will create an OAuth Key if the portal system is enabled and will allow for portal authentication. Other client_id's can be created by the administrator in the OAuthKeys section in the Administration section and can be used in the future for additional grant types, if the client secret is filled in, it will be checked to validate the use of the client id.
client_secret	String	The client's secret key.
username	String	The username of the user authenticating to the system.
password	String	The plaintext password the user authenticating to the system.
platform	String	Defaults to "base" allows you to have custom meta-data per platform. If using a value other than "base", you should make sure it is registered using the Platform extension or configure an API platform in Administration panel.

First, we are going to log in using a grant_type of "password" and a platform of "custom". Normally, when logging into Sugar, users log in with a platform type of "base". We are using "custom" to avoid any potential login conflicts.

        curl -X POST -H Cache-Control:no-cache -H "Content-Type: application/json" -d '{ 
    "grant_type":"password", 
    "client_id":"sugar", 
    "client_secret":"", 
    "username":"<username>", 
    "password":"<password>", 
    "platform":"custom" 
}' https:/<site_url>/rest/<version>/oauth2/token

Once you get the response you will need to hold onto the access_token and the refresh_token. Anytime the access_token is invalidated, you will want to make another request to the token endpoint with a grant_type of "refresh_token". Store just the refresh_token in long-term storage – not the username and password. The response from the server will be as follows:

        {
    "access_token": "5ee48ec7-023e-ecff-5184-530bd0358868",
    "expires_in": 3600,
    "token_type": "bearer",
    "scope": null,
    "refresh_token": "5f197357-0167-f7a6-7912-530bd03275b6",
    "refresh_expires_in": 1209600,
    "download_token": "5f531625-e301-e3ea-1b11-530bd098be41"
}

Avoiding Login Conflicts

Login conflicts often occur when building integrations or running data migrations with the platform of "base" or any other client type that is in use. This is due to the fact that Sugar uses the same REST API to power all the various clients such as Sugar, Portal, Mobile, and even the Outlook Plugin. Due to this, you need to let the API know you aren't conflicting with another client that may be in use. The way to accomplish this is the /rest/<version>/oauth2/token call by changing the platform parameter to something other than "base", "mobile", or "portal". It is best to name it something that describes and identifies your current integration.

Input / Output Data Types

The default input / output datatype for REST is JSON.

Date Handling

Date and date time inputs should be formatted following the ISO 8601 format. If the time zone is not included in a request, Sugar will assume the time zone of the user making the request.

Filter on a specific date:

        {
    "date_start": "2015-08-12"
}

Filter on a date keyword using $dateRange:

        {
    "date_start": {
        "$dateRange": "today"
    }
}

Filter on date range using manual time zones:

        {
    "date_start": {
        "$dateBetween": [
            "2015-09-10T00:00:00+10:00",
            "2015-09-10T23:59:59+10:00"
        ]
    }
}