Skip to content

Guide to constructing an API request

  Less than to read

This document is a step by step guide to building an application utilising the RESTful API for Sage 200 Standard and Sage 200 Professional.


Caution: The authentication method below has been deprecated, 19th Febuary 2021. For an updated version of this guide, please see the Authenticate with the Sage 200 API guide.


The API is a RESTful data service which provides programmatic access to read and write data, allowing developers to make HTTP requests and receive responses. The API uses the OAuth 2.0 standard for authentication. OAuth 2.0 is a widely recognised framework for authentication and is globally used in APIs. This is a process of exchanges that allow a user to grant access for an application to access their data set. You can read more about OAuth 2.0 here.

These requests use the following HTTP verbs to determine the request functionality:

GETThe GET method requests a representation of the specified resource. Requests using GET should only retrieve data and should have no other effect. i.e. Retrieve data /records.
POSTThe POST method requests that the server accept the entity enclosed in the request as a new subordinate of the web resource identified by the URI. i.e. Create data / records.
PUTThe PUT method requests that the enclosed entity be stored under the supplied URI. If the URI refers to an existing resource, it is modified. i.e. Modify data/ records.
DELETEThe DELETE method deletes the specified resource. i.e. Deletes data / records.

Note: If you are developing or testing API requests using Postman, we have also produced the following guide which you may find helpful, see here. This guide will cover a lot of the content discussed below in the context of the Postman application.

OAuth flow

The client requests authorization from the resource owner. The authorization request can be made directly to the resource owner, or, preferably, indirectly via the authorization server, which acts as an intermediary.

The client receives an authorization grant, which are credentials representing the resource owner’s authorization. These are expressed using one of four grant types and are defined in this specification or using an extension grant type. The authorization grant type depends on the method used by the client to request authorization and the types supported by the authorization server:

  • The client requests an access token by authenticating with the authorization server and presenting the authorization grant.
  • The authorization server authenticates the client and validates the authorization grant, and if valid, issues an access token.
  • The client requests the protected resource from the resource server and authenticates by presenting the access token.
  • The resource server validates the access token, and if valid, serves the request.

Confidential or Public Client

There are 2 ways to access the Sage 200 API, via a Confidential Client or a Public Client.

Public Client:

Mobile and Desktop applications are classed as a public client types as they would need to store the client and secret locally, and securely, which are then used as part of the Sage ID user authentication process. This is potentially less secure as the client and secret would need to be distributed with the compiled applications. To improve security, a temporary certificate is issued by Sage ID to secure any communication between the application and Sage ID

Confidential Client:

Web based applications that store the Client and Secret keys on a server are classed as Confidential Clients. They are more secure because only the server has access to these keys; they are not distributed to end users


When you register your application for the Sage 200 API, you are provided with:

  • A Client_ID
  • A Scope

If you are using a confidential client, you will also be provided with:

  • A Secret Key

Caution: You must store these credentials securely and not share these with anyone. You must also not check this information into source control.

For confidential client, you will register one or more redirect URLs with Sage that will be used during the OAuth process to redirect the user back to your application. For testing and development purposes you do not need to register your application and can instead use our demonstration credentials. Please contact Sage Developer Services there contact details can be found here if you require these. To register your API application, for a production environment, and receive your API Credentials, please complete our request form.

Access and refresh tokens

Access tokens are used to authenticate API requests. Without a valid access token any request will be denied. Access tokens are set to expire after a specified amount of time, for a maximum of 60 minutes for the access token and 180 days for the refresh token. When a successful request is made to generate a new access token a refresh token is also generated. When an access token expires, your application can be configured to either have the user login to requests another access token, or the refresh token can be used to generate a new access token without user interaction up to the lifetime of the refresh token.


Note: Authentication for the Sage 200 API requires user interaction, either by requesting a new access token or a new refresh token. This cannot be circumnavigated, or automated.

Access tokens are specific to the Sage ID used to request the token and therefore share the same level of authorization and permission within the Sage 200, as the user who made the request.

Base URLs

The Base URL for your request will differ based on the Sage 200 application.

For Sage 200 Professional/Extra Online you need to ensure the following Base URL being used is:

For Sage 200 Standard this would be:

The following demonstrations will assume you are using a confidential client.

Authorization Request

You will need to start by authenticating your application. This is achieved by sending a request to the Sage 200 Authorization Server with the following information:

Request URL:

OAuth requires all parameters to be URL encoded and concatenated with an ‘&’.

Header Parameters Value
response_type code
client_id This will have to be generated by Live Services, however, for demonstration credentials, please contact Developer Services.
redirect URL The URI which will receive the result of the authentication. This is case sensitive, and must match a URI that is registered against the Client ID.
state A string used to protect against Cross-site request forgery (C SRF) attacks. Although state is optional, we recommend including this. This should be a string that cannot be guessed.
scope See Client ID.

Note: If the value of the state parameter returned in the response does not match the state that was provided in the original request, it does not originate from the original request and you must not continue.

Example Request:


When this endpoint is queried, the user is prompted to sign into with their Sage ID and asked if they want to authorise the application. If the user allows access to your application, they are redirected to the redirect URL along specified in the request with an authorization code which can be read from the response.

Example Response:


Access token

Once your application has been authenticated you will then need to request an access token in exchange for the authorization code.

To do this, you will need to send a POST request to the following URL:


Required header parameters:

Header Parameters Value
Authorization “Basic “ + < secretkey >
ContentType application/x-www-form-urlencoded;charset=UTF-8

Note: The < secretkey > consists of your client_id and _secret base 64 encoded and concatenated with a ‘:’

Required request body parameters:

Request Body Parameters Value
grant_type authorization_code
code The authorization code returned in the previous step (see Authorization Request.)
redirect_uri The URI which will receive the result of the authentication. This is case sensitive, and must match a URI that is registered against the Client ID (see Credentials). All parameters need to be URL encoded and concatenated with an ‘&’.

Example request body:


Example Response:


Using the refresh token

During the authorization exchange, you are issued with an access token and a refresh token. You must include the access token in each API call.


Note: The access token has a short expiry. The maximum lifetime of an access token is 60 minutes.

You can use a valid refresh token to obtain a new access token without requiring the user to sign in again, up to the expiry of the refresh token. To do this, you will need to send a POST request to the following URL:

Required header parameters:

Header Parameters Value
Authorization “Basic “ + < secretkey >
ContentType application/x-www-form-urlencoded;charset=UTF-8

Note: The < secretkey > consists of your client_id and _secret base 64 encoded and concatenated with a ‘:’

Required request body parameters:

Request Body Parameters Value
grant_type refresh_token
refresh_token The refresh token generated by your previous request (see Access Token).

TIP: All parameters need to be URL encoded and concatenated with an ‘&’.

Example request body:

grant_type=refresh_token&refresh_token= 6Z3IFJE80HAG9R633ICV8EC64B401P28B6ER2D1E2O754QAA312D476ABR1W5Z4L5K0EEZ767BAXEV6D344SA5CB4F4N39E6ATCTEF983J4KBL9U9N45CQ4KCJ0K1K5Z

Example Response:


Making a Request

With a valid access token, you are now authorised to make API requests. A request consists of various attributes which must be built up prior to sending the request.The API has several endpoints and operations available. These are essentially URLs available to make requests to.

For example, a GET request to the customer’s endpoint will return all customers, whereas, a POST request to the same endpoint will create a new customer.

All the available endpoints and operation can be found here. The documentation for each operation provides information on available/required fields and OData query parameters.

Once you have determined which HTTP method (operation) and endpoint you wish to use you will need to construct the request header and body.

Header parameters:

Headers include information about the HTTP request and about the data that is sent with the request body.

As part of your header you will need to supply the following values for each HTTP request:

Header Parameters Value
ocp-apim-subscription-key Your Developer Subscription Key.
TIP: Your developer subscription key is a unique ID which is used when making API calls against your account. It is therefore important that these keys are not shared. For further information on acquiring your developer subscription key please see here.
Content-Type application/json
TIP: This informs the server/client the type of content that is being sent/recieved. For the Sage 200 API this would be JSON, therefore, this value will always be set to: application/json.
Authorization A valid access token (if authenticating using Cloud ID)
TIP: This is the access token that you have generated, prefixed with the string “Bearer “(note the space affixed to the end of Bearer).
X-Site The site_id value of the Site.
X-Company The company_id of the Company.
TIP: These values are the ID of the site, and the company, you would like to send your request to. These values must be passed on every request, with the exception of a GET request to the sites endpoint, which is used to obtain these values. For information on the sites endpoint here, for Sage 200 Professional/Extra Online, and here, for Sage 200 Standard.

CAUTION: If you omit to add to a space you will the following error in your response body when you attempt to make an API request: “Message”: “Authorization has been denied for this request.”


Bearer /iHBw7SRGqO/TXoCD975Rp2D5IytZC6xylKf4FxxMQ2kN1bXJbRnfyfTqXe6gJokkXPUC/3wnVjNp0n75yrIZDtRi2epuIq3+j2zIm7wNK5y2IpO/X/psHz0dUEmCBg81dPReHA8eSxvyd+bOfM9SNvw2G9bRwBZy6eHkqBpZ7h6oVWz9V94se/qAQuwFM3oppdC9b6pDpUs2VF+7j5DY5VIdajLsRVhABeXBallafiCpsmvdhjfobUm4Upgyip4QV/6zArX0szCj0wJ4CjHZ2mqOkmkmcUoW6QgYR5O4oReN+ZOD4hkIGsiK+yPmcJeZU4575Uby1KIcFxkbd0PeNxafr3foVvaGGQUGw0d2lT028Akv+D3VTsm628eV1SkUouMBjQLkWjgtW/klChnHkKHpb93aDv4PjyqcwGfm1DYxeX/E0lQ837L0SpRZVctWbqFZ/6ZgGNabYaH1WS0G3JpYoxVDv/iXxJaU/4OgBFrk22HVkDsms0aR1n1hez5LeJoqqWeb3OnbwOiDBaDsdKhGruibTynx1FqFDXY77n3mzwYJSTdgzWVaqWwqRT3VWIQgULu5Jb3UnpPWKrDGZQPlC0fX6kqfeov6xD7OsHA8FgkW9P4wPXob4LZK3Wy6ScmGhjz7dGuVGXdP+YL2LgJa5Hs2EiBGnNuDQo4Z2HskG7ZB5z8WVmnI57sMV1RxHhBvcTqzCq+jo0rUTVzZvpJSKA134ZZaPX3OF12qweud2VYq0q50I1Ak5c1A0E5j58Qnv+hd9M02URwe68KLjkO7ibiW1nqq/b+b3MsGv7Z5TCz7IwPLd18nQSmjRr/oaz1xDnuP3CGJ03i3xrhE66MQKt5bvM4FxZBoMpo8D3M5v92hAIsF4qK1dw+sBEWR8D7uI+EHwizBkglW/D8VzQ6skL9aDZbt8B+HyUInh8m1R6BOTGYCR8IKtSvDnP4pdoxvNCI8amRmGWL9Ztx3PVF20kb13SilbREKUj+V8Fw+uugrU9Edw+YGHbhu2FH2YwuG0o7Ax9uOPS1wKlyFk93GKCJUw8bwot2nB3iVKAxUBa/OPYbei+h9YZNQqBdmkHbC/PI5m670/YdAZa1AKztuRaS65XpQBq3HupAxQRa3DUgMyfHRlDG9Mw1YwMxlL3JNwIqRp+yFy7Lb33hcIG6VKoiYIMK4PtAUMJnkjF20tf5dUfMoyqEhehZ7u89AVsjzxvGwZDdFL8okC6z1c5Nokpo0hO/awl3J3pCCjSmkZU9DXUkvc0S26ThEtVO5a8eaZS9UBJ+oo3pE3iNTJBT01UW9Yy3xQG91JRm9RoaGxr8xDw1EcblpFtoiH4w+KJrSaXIqOi8QWavUAmx4/q3tO5Jzna5ZWY/9KI7V1OpTiSWom42cO1NGGEVT6BELbenOVw3R2VMGFFv9Y3b/74k3TQd5ae/TO9ifzDRVqP46kYKvHEKLxbpzbY+O6ChFh6VEmsVfhMJ88p2uC79QepHQWbfDHqdaJwdygCUz06Euw8V8SqNJAAst0JnpTBXK741qZmUD3gQ8xd+HuGn4bVms45GmFonH9V6HGImFKOcMm1S6cwwzLwJE4GNTkFQpXYlLY9yXPTd7Yv0kvbvNvnUU3Y9a6DCHA9YqeoDUHBh71SVo/ExqZ8a2thIoYTKSVY04uudQg7MGbKyh/XCdIQtu21tYSGRsrX40ZfcfWpPOX4bsPXRyNMjUWSq5ogTCLAd1afIiCJ3fQmsgB7r/42GVYfhua6tMcvmWyPFXK2GLJ2tq3lcVLA+HHqP+mard+Hf5k1ZzrawXOjcPCfUyf7smQRa1BGekTE11ikbw8dihk7eQQlmsVrBNUPReR+aFIYadnhVS+tGzEQecA5ZauAPewC0WwjrT8DKMZ23jYsYYeZYOrZDzhAoN5xNHXKGRngWEJ7+fzZ8pAcAk3KFaIDzwjxUdANSQsbaHbqXtQ3iaqFqRl+HbdJ10isjSdsDAMocftOrXEH5SrrzxV1W2g==

Request Body Example: This is an example of a JSON request body for a POST request to the customers endpoint.

    "reference": "APITEST",
    "name": "API Test",
    "short_name": "APITEST",
    "on_hold": false,
    "account_status_type": "AccountStatusActive",
    //Currencies endpoint
    "currency_id": 63956,
    "exchange_rate_type": "ExchangeRateSingle",
    "telephone_country_code": "00",
    "telephone_area_code": "1234",
    "telephone_subscriber_number": "567 8899",
    "fax_country_code": "00",
    "fax_area_code": "1234",
    "fax_subscriber_number": "567 9988",
    "website": "",
    "credit_limit": 2500.00,
    //Country_codes endpoint
    "country_code_id": 63946,
    //Tax_codes endpoint
    "default_tax_code_id": 1287,
    "duns_code": "000000001",
    "contacts": [
            "salutation_id": 0,
            "name": "Api Test",
            "first_name": "Api",
            "middle_name": "",
            "last_name": "Test",
            "is_default": true

Further Information:

Setup and Configuration: Information on setup and configuration of the Native API, using Microsoft Azure Active Directory tunnelling, can be found here.

API Setup and Responsibilities: Information on who responsible for each area of a Sage API deployment can be found here.

FAQ: For a list of frequently asked question regarding the Sage 200 API, please see here.

Getting Started with Postman: This guide provides steps to making API request to the Sage 200 RESTful API via Postman, and can be found here.