Where authentication is required, API calls are authenticated using the Authorization header. The Sugarcoat API supports 2 forms of authentication; API Keys and API Tokens.

Within the API Settings area of your console, you should have access to a Private Key and a Public Key. Both keys can be used within the Authorization header to make API requests however each key has different persmissions and access scopes within the API.
If for any reason your API Keys are compromised, you should regenerate new ones via the API Settings and update your integration.

Private Keys

Private Keys have complete access to the API and therefore MUST be used over a secure connection and MUST NEVER be shared or visible in your application.
This can be used for server-to-server integrations between your application and the Sugarcoat API.

Public Keys

Public Keys can only access public API endpoints and will result in a 403 status code response if used to request data outside of that scope.
This can be used for client-to-server integrations between you application and the Sugarcoat API.

API Tokens give temporary access to API endpoints and can be generated via the token endpoint using either the, Private or Public API key. By default, API Tokens can only access public endpoints (the same as Public Keys) however they can be elevated to give permissions to certain resources or scopes e.g. a User.
NOTE: If an API Token is used to authenticate a login request, if it is successful then the token will be automatically be elevated to the user so the token can be used for future User actions.

Errors returned from the Sugarcoat API aim to be consistent and give the maximum flexability to the integrators to be able to handle them effectively. Any errors returned with be in an errors node as an array of objects in the following format:

Response

The Sugarcoat API utilises page-based pagination thoughout and when calling list endpoints, the fields count, current_page,last_page and interval will be returned in the response allowing you to navigate through pages with the simple querystring filtering of ?page=<page_number>, for example: /orders?page=3. You can also pass in the pagination_interval parameter for the items per page, for example /orders?page=3&pagination_interval=5. When no more pages are available, the next_page key will return null.

Request

Endpoints which are filterable or paginated can be sorted by an array of values. These are provided in the format products?sort[0][property]=name&sort[0][direction]=asc&sort[1][property]=created_at&sort[1][direction]=desc

Request

Endpoints which return collections of information can be filtered further by the properties returned. These are provided in the format products?filters[0][property]=name&filters[0][value]=test&filters[0][operator]=LIKE

Request

Listing endpoints may return a compact response for a given collection to save on data transfer and increase performance. Further relational data can be obtained either from a subsequest request to that individual resource or by including additional the relationships in the listing response. These relationships can be added via the include parameter with a comma seperate set of values e.g. products?include=tags,category_options,images

Analyics allow you track and report on metrics that matter to your business.

Manage the baskets that exist on your store with the ability to analyse and report on these baskets.