Access token expires every 1 hour (3600 seconds).
Refresh token expires after 1 month.
Authorization code is active for 10 minutes and can be used only once.
It’s possible to request more than one pair of tokens at once using the same old refresh token. The old refresh token won't be invalidated until you’ve used the access token from the new pair. This enables you to get new access tokens several times in case of outages or maintenance on our end.
Minimum 1 x a month and maximum 1 x an hour a token should be refreshed.
If the Refresh Token expires, then the app needs to be re-authorized, please see OAuth 2 flow from 1. Initiate OAuth .
Yes, we do accept sub domains as the OAuth redirect URL. Not a problem at all.
Yes there are some limitations.
- We do not accept redirect_uri with wildcards, for example, you can not register https://*.mydomain.com so that you could send any subdomain in parameter. SSL certificate (https://) is necessary and non-negotiable.
- Currently we cannot accept dynamic parameter in redirect URI
OAuth can be used to authenticate your desktop client into Cloudbeds API. OAuth authentication flow requires you to use an endpoint on your side (named redirect url) to which we'll redirect the user with an authorization code that can be used to retrieve access and refresh tokens that work as authentication credentials on all the other requests you may submit to Cloudbeds API. "localhost" can be used as such endpoint, but your desktop app should be able to render a HTML page in which your users will log into Cloudbeds account, and it also should be able to receive and parse HTTP (in dev stages) and HTTPS (beta and live stages) requests.
No, Cloudbeds can't be used as an identity provider and can't be used for SSO.
The Cloudbeds API has the following polling limits. While these are enforced, we do allow some margin of error. We encourage all to respect the following limits:
Properties and Group Properties:
5 requests per second
10 requests per second
Methods and parameters
We don't offer a test server, but we do offer a Technology Partner Test Accounts on our production server. It has dummy data and will allow you to try out your integration.
With the same account you will manage the details (app screenshots, app icon, copy) of your app in our App Directory.
Allowed values are property based. Possible strings are:
Here is the list with their names and codes:
- Brazilian Portuguese-pt-br
Ideally, we allow up to 6 calls to be used for an integration. Depending on your use case additional 1-2 will be allowed.
To post a rate, it must be registered in MFD. It is possible to see all rates using /getRatesPlan. getRatesPlan returns all rates/plans, independent of it being applicable to the dates (sent in the request). The difference is, if the plan isn't applicable, it will send many fields with the value 0 (example: "roomsAvailable": 0). This means that the plan isn't applicable to the parameters given.
As said, the call must be registered in MFD. At the moment, there's no call that allows that to be done with the API.
It doesn't take into consideration any applicable rate plans or promos (especially because no promo code can be sent to the call).
No, getTransactions provides the list of transactions already posted into myfrontdesk folio.
For example, if you want to see all of the guests/reservations for February 26, 2021 use these filters:
One test pilot property is enough, but up to 5 will be allowed in case there's a lot of interest from mutual customers.
We suggest using Postman (https://www.getpostman.com/) for testing and understanding the overall usage of our calls. Although we do not give support, we do offer our public API Collection of calls that can be used in Postman. See video in our Set up environment & test OAuth 2 in Postman article to get help.