Getting Started

Welcome to Fourth's API documentation! This page provides guidance on integrating with Fourth's REST APIs. To discover all the possible ways to integrate, please see Integration Options.

Request credentials

We highly recommend that your first step is requesting credentials.

Live credentials

API credentials are linked to customer accounts. Therefore, you must ask your mutual Fourth customers to request credentials for your use. Credentials can take 2 to 4 weeks to provision.
Customers using our Fourth Inventory for Hotels (Adaco) solution generate the API credentials themselves. Instructions on how customers can do this are on the guide pages for each of these APIs.

Test credentials

With our test environments, you can use a separate set of test credentials. You can request these directly from your Fourth integration consultant.

Request host details

We do not currently show our production or test host locations. Therefore, before you can begin you will also need to contact Fourth to get the host details for the APIs you wish to use.

Customers using our Fourth Inventory for Hotels (Adaco) solution may have their own unique hosts.

Read the documentation

This website holds all our guides and OpenAPI references for our publically-accessible REST APIs. If you are interested in extending an API or need further help, don't hesitate to get in touch. Some API solutions are only available after discussion with our integration team.

Understand authentication

Our APIs use either OAuth 2.0 or Basic authentication.

Using OAuth 2.0

For information about using OAuth 2.0, see our dedicated page: Authenticating with OAuth.

Using Basic authentication

To use Basic authentication, you must include your Fourth username and password in the request header. The username and password must be joined with a colon inbetween; for example:

  • exampleUsername:examplePassword

You then need to base 64 encode this string (into the UTF-8 character set). For example, exampleUsername:examplePassword becomes:

  • ZXhhbXBsZVVzZXJuYW1lOmV4YW1wbGVQYXNzd29yZA==

Add this to the Authorization header as Basic encoded-string:

GET /{customerName}Service/WebApi/ExchangeRates  HTTP/1.1
Host: instance.example.com
Authorization: Basic ZXhhbXBsZVVzZXJuYW1lOmV4YW1wbGVQYXNzd29yZA==

Test your integration

Test with Swagger

Most of our REST APIs have Swagger endpoints that allow you to view the documentation and test requests. These are reached through the endpoint:

  • [ROOT]/{path}/swagger/ui/index

Swagger has the option to test API calls; however, to do so you need to authenticate your requests. This is possible for some our APIs by selecting the ! icon for the request method:

Screenshot of the Swagger page for an API

The test interface of APIs that require OAUTH, such as the Tasks or Notifications API, may also accept Basic authentication from the Swagger UI.

Screenshot showing the authentication dialog for a Swagger endpoint.

Understand the response from Fourth

Fourth uses standard HTTP response codes to indicate whether a request was successful.

Code Description
200-299

Indicates that we accepted your request.

Note though that, even if a request is accepted, there may be in issue with processing the request further.

400-499

Indicates that there was an issue with the request that you will need to resolve.

You will need to review the error message in the response and update your request as necessary. Do not retry your request until you have resolved the issue.

500-599

Indicates that Fourth experienced an issue with receiving your request.

You may retry your requests using a truncated backoff strategy. Please retry requests no more than once per minute.

Create a retry strategy

If you receive a 500-599 response, then you should retry your request using a truncated backoff strategy; for example:

  • 1 minute > 2 minutes > 4 minutes > 8 minutes > 15 minutes > 30 minutes > 1 hour > 2 hours > etc...

Please retry requests no more than once a minute. Get in contact with Fourth if the issue is ongoing.

If you do not receive a response, them you will need to consider how you want to respond based on the API:

  • If you are sending a push notification through the Tasks API or Notifications API, you may want to restrict your retries so that you do not keep sending the same message through to a user.
  • For other APIs, if the API request is not idempotent, (for example, some POST requests will create new resources with each request) you may decide to not retry the request automatically. Please check each APIs behavour when integrating.    

Join our Partner Program!

Make sure you join our partner program to get access to a range of benefits. For example, this can include being listed in our Partner Program Directory for customers to browse.

JOIN NOW