Getting Resources

To fetch resources from the Bedful API, use get requests, with the appropriate authorisation. You should contact bedful developers first to ensure you have the correct access before attempting to connect.

Authorisation

You will only be allowed to access resources which have been assigned to your channel. If you wish to have access to a particular property/unit and don't have access currently, please contact the API team. A 401 error indicates that your channel does not have access to a given resource.

Testing

While testing, you can use the dev api server. This contains a sanitised copy of the data from the live servers you have access to, so the data is like the real data you'll use on the live servers. The dev server can be found here:

https://devapi.bedful.com

You can get and set the same resources as you do on the live servers, but there will be no impact on the live data, as the dev servers use a parallel set of test data.

Test data will be wiped every week on Monday AM, so you should not depend on any test data remaining for the long term - this should solely be used for testing your integration in an environment similar to the live api.

Curl Examples

Examples for the API use curl, as it is widely available and simple to get started with, but we expect you to use an HTTP library for the language used by your servers to access the API. You should not use curl in production.

Fetching a Resource

To fetch a resource, make a get request using the resource ID. All our examples use curl for simplicity, but of course you should use the library of your choice to perform GET requests within your application. For example to fetch information on a single booking, make a GET request to the url:

curl -u BEDFUL_KEY: https://devapi.bedful.com/bookings/:id

where ID is the booking id in question. You can see the detail of the response you'll receive in Getting Bookings.

Expanding Resources

You can also expand most resources by passing in an expand=true param in order to see details of sub-resources in the same request. Use this sparingly because it increases the amount of data served significantly.

Errors and Retries

The API uses the standard HTTP error codes to report results, and error codes and their meanings are summarised below. Broadly, if you receive a 40x error, it means the error is in the request and you should not retry with the same parameters. If you receive a 50x error, this means the error was on our side and may be a transient one. Errors typically also include a short explanation of the problem for humans.

• 200 – OK – the request was successful
• 302 – Found – the request was successful and a redirect to the resource
• 400 – Bad Request – please check the parameters and request body before trying again
• 401 – Not Authorised – please check the credentials before trying again
• 404 – Not Found – the resource requested could not be found, please check the ids requested
• 500 – Internal Error – the server encountered an error. Please retry with exponential backoff (i.e. retry in 1 minute, 10 minutes, 100 minutes).