What makes an API request

URL Structure

An example of a Sage API URL structure: https://sage200.sage.es/api/sales/Products

The structure of the URL example shows a product resource entity for the Sage 200 API. Any request made to this resource entity will be made implicity to version 1 of the API.

https://sage200.sage.es/api/sales	Base path
Products	Resource entity

Headers

Headers include information about the HTTP request and about the data that is sent with the request body. To use any Sage API you need to supply these headers below, along with their corresponding values for every HTTP request.

X-Site	Installation ID of the Sage 200 application
X-Nonce	Unique identifier assigned to this request, for tracking capabilites. It’s strongly recommended to use a random generated GUID for each request.
ocp-apim-subscription-key	Developer subscription key
Authorization	Bearer access token
Content-Type	Always set to application/json

HTTP response example

With every request to the API, a response message will be returned.

Here is a response message example.

Response Code	400
Response Message	Bad Request
Response Body	{ “statusCode”:400, “message”:”Required header Authorization not found” }

HTTP response codes

With every request made to the API, a response code will be returned. The response code indicates if the API request is successful or not, and what may have caused the API request to fail.

Here are a few common response codes:

200	Ok. The request was successful.
201	Created. The request successfully created the resource.
204	No Content. The DELETE operation was successful.
400	Bad Request. This occurs if the data that you are sending over is malformed or contains invalid fields and values in headers, query string or in the body of a request. The API will attempt to return meaningful error messages relating to the cause of the first error it encounters.
401	Unauthorized. Authentication credentials were missing or incorrect. For example, token has expired, Bearer header is not informed, or token is malformed.
403	Forbidden. The request is understood, but it has been refused or access is not allowed. An accompanying error message will explain why. The user does not have the necessary permissions for the X-Site or resource. This code is also used when requests are being denied due to API limits.
404	Resource not found. The requested X-Site or resource could not be found but may be available in the future. Subsequent requests by the client are permissible.
413	Request Entity Too Large. The request is larger than the server is willing or able to process.
429	Too Many Request. Indicates that you are sending too many requests in a given amount of time (“rate limiting”).
500	Internal Server Error. A generic error message, given when an unexpected condition was encountered and no more specific message is suitable.
503	Service Unavailable. The server is currently unavailable (because it is overloaded or down for maintenance). Generally, this is a temporary state.
524	Origin Time-out. API is currently unavailable - typically due to a scheduled outage - try again soon.