This documentation describes the possibilities and processes surrounding the Kobas API. This API is intended for use by technical teams working for or acting on behalf of companies who use Kobas hospitality management software. If you need more information about integrating with Kobas please contact us at email@example.com.
API – Application Programming Interface, a set of defined methods that can be used to communicate with a software system.
HTTPS – Hyper Text Transfer Protocol Secure, the combination of SSL/TLS and HTTP resulting in a secure, stateless transfer of data over commonly used HTTP.
OAuth – OAuth 2.0 is the industry-standard protocol for authorisation.
RESTful – REpresentative State Transfer.
The Kobas API is RESTful and operates over HTTPS, exchanging data using JSON. No other notation or transfer protocol is supported at this time.
API is not available over HTTP without SSL/TLS encryption.
Our API uses OAuth 2.0’s ‘client credential access tokens’ that have a 1-hour expiry. This allows you to use any standard OAuth library or tools like Postman to easily communicate with our API. You can request an access token by submitting a POST request to https://oauth.kobas.co.uk/access_token with the following body:
This will then return you a token + expiry time, allowing you to communicate with the API.
Note: To ensure compliance with all OAuth 2 libraries and tools, “x-kobas-company-id” can also be sent as a GET variable.
All HTTPS requests should be directed to: https://api.kobas.co.uk/v3/ with an appropriate verb and endpoint.
The API exposes several endpoints for data exchange and activity. All available endpoints are documented along with example output at https://api-doc.kobas.co.uk
The API accepts the following verbs:
The API will accept a PUT request that creates a new resource at the specified location. If a resource already exists at that location, it will be overwritten. A POST request must never attempt to specify a location.
Authorisation: Bearer [your_access_token]
DELETE and GET requests expect data in the query string. POST and PUT requests expect information in the request body.
Content-Type, Encoding and Compression
POST and PUT requests should be in one of the following formats, with a valid Content-Type header to match:
The API servers support gzip compression and customers are urged to use this where possible to minimise bandwidth usage for all concerned.