REST API
Overview
v10 - v11.24 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"
]
}
}