REST API

Overview

v10 - v11.20 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:

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"
        ]
    }
}