|
|
| (58 intermediate revisions by 4 users not shown) |
| Line 1: |
Line 1: |
| − | [[Category:Apps]] | + | #REDIRECT [[:Category:API_V2]] |
| − | [[Category:API]]
| |
| − | [[Category:Automation]]
| |
| − | | |
| − | <div class="heading">API Version 2.0</div>
| |
| − | | |
| − | This page explains the capabilities of the API Version 2.0 and explains how to use it.
| |
| − | | |
| − | = Capabilities =
| |
| − | API V2 can allow third parties to access your account, properties, bookings and inventory.
| |
| − | | |
| − | = Authentication =
| |
| − | To use most API endpoints you will need to include a token header.
| |
| − | | |
| − | '''Step 1: Get an invite code'''
| |
| − | | |
| − | Invite codes can be generated here [https://beds24.com/control3.php?pagetype=apiv2 Invite Codes]
| |
| − | | |
| − | For more information about invite codes, [[API_V2.0#Invite_codes|see here]].
| |
| − | | |
| − | This step is the only one that must be done manually, all other steps can be performed and automated programmatically.
| |
| − | | |
| − | '''Step 2: Get a refresh token using the invite code'''
| |
| − | | |
| − | You can use the invite code generated in step one with GET /authentication/setup.
| |
| − | | |
| − | This will return a ''token'' and a ''refresh token''.
| |
| − | | |
| − | '''Step 3: Use the token to authenticate calls'''
| |
| − | | |
| − | The ''token'' returned in step 2 can be included as a header to authenticate calls to other API endpoints.
| |
| − | Note: ''tokens'' expire after 24 hours.
| |
| − | | |
| − | '''Step 4: Use the refresh token to generate new tokens'''
| |
| − | | |
| − | As ''tokens'' expire after 24 hours, you will need to use the ''refresh token'' with GET /authentication/token to get new tokens when old ones expire.
| |
| − | | |
| − | = Invite codes =
| |
| − | To grant a third party access to your account, you will need to provide them with an invite code.
| |
| − | | |
| − | == Create a code from a link given to you by a third party ==
| |
| − | | |
| − | If you are given such a link, most fields will be filled out for you.
| |
| − | | |
| − | You simply need to decide if the third party should be able to access your linked properties.
| |
| − | | |
| − | Click the Generate invite code button and give the code to the third party.
| |
| − | | |
| − | == Create a code to give to a third party ==
| |
| − | | |
| − | '''Step 1: Select what the third party can access'''
| |
| − | | |
| − | Click the generate invite code button and select the scopes of the invite code.
| |
| − | Scopes determine what the third party will be able to access, and what they can do with it.
| |
| − | See the scopes section for more information.
| |
| − | | |
| − | | |
| − | '''Step 2: Linked properties'''
| |
| − | | |
| − | Decide if you want the third party to be able to access your linked properties, or just the properties in your account.
| |
| − | | |
| − | | |
| − | '''Step 3: IP Whitelisting '''
| |
| − | | |
| − | If you add an IP address here, only that IP address will be able to access your account using the invite code.
| |
| − | | |
| − | Multiple IP addresses can be added if separated by commas, e.g.
| |
| − | 192.168.0.1, 127.0.0.1, 2001:0db8:85a3:0000:0000:8a2e:0370:7334
| |
| − | | |
| − | | |
| − | '''Step 4: Create the invite code '''
| |
| − | | |
| − | Click the Generate invite code button. You will now see the code listed in the table. Copy this code and give it to the third party.
| |
| − | | |
| − | == Create a link to give to users (as a third party) ==
| |
| − | | |
| − | If you are a third party who requires invite codes from users, you can give users a link that will prefill the form with the scopes you require selected.
| |
| − | | |
| − | To do this, select the scopes you require then click the button in the bottom left corner to see your customized link.
| |
| − | | |
| − | You can also prefill a whitelisted IP address in the same way
| |
| − | | |
| − | = Scopes =
| |
| − | Each category of API endpoint (except /authentication) requires a corresponding scope to access.
| |
| − | | |
| − | == bookings ==
| |
| − | The '''bookings''' scope provides access to basic information for
| |
| − | GET /bookings
| |
| − | POST /bookings
| |
| − | | |
| − | == bookings-personal ==
| |
| − | The '''bookings-personal''' scope provides access to personal information (in addition to the basic information granted by the ''bookings'' scope) for
| |
| − | GET /bookings
| |
| − | POST /bookings
| |
| − | GET /bookings/messages
| |
| − | POST /bookings/messages
| |
| − | PATCH /bookings/messages
| |
| − | | |
| − | == bookings-financial ==
| |
| − | The '''bookings-financial''' scope provides access to financial information (in addition to the basic information granted by the ''bookings'' scope) for
| |
| − | GET /bookings
| |
| − | POST /bookings
| |
| − | | |
| − | == inventory ==
| |
| − | The '''inventory''' scope provides access to
| |
| − | GET /inventory/offers
| |
| − | GET /inventory/availability
| |
| − | GET /inventory/calendar
| |
| − | POST /inventory/calendar
| |
| − | | |
| − | == properties ==
| |
| − | The '''properties''' scope provides access to
| |
| − | GET /properties
| |
| − | POST /properties
| |
| − | | |
| − | == accounts ==
| |
| − | The '''account''' scope provides access to
| |
| − | GET /accounts
| |
| − | POST /accounts
| |
| − | | |
| − | | |
| − | | |
| − | Some categories have additional scopes that allow access to personal or financial information. For example, the "bookings" scope would grant access to a booking's basic information such as the check-in and checkout dates. To access personal information such as the name of a guest, the "bookings-personal" scope would be required. Similarly, to access the invoice of a bookings, the "bookings-financial" scope would be required.
| |
| − | | |
| − | Each scope must also have an accompanying method. For example "read:bookings" would grant read access to bookings, but in order to create a new booking "write:bookings" would be required.
| |
| − | | |
| − | The "all" method may be used as a shortcut to grant access to all methods. For example "all:bookings" would allow for the reading, updating, creating and deleting of bookings.
| |
| − | | |
| − | = POST requests =
| |
| − | == Creating/modifying multiple items ==
| |
| − | All POST endpoints accept an array of items (an item may be a booking, message, property etc).
| |
| − | | |
| − | It is possible to create and modify multiple different items in one request this way.
| |
| − | | |
| − | All existing "POSTable" items will have an "id" field to uniquely identify it.
| |
| − | * To create a new item, just do not include an id.
| |
| − | * To modify an existing item, include its id.
| |
| − | | |
| − | == Subitems ==
| |
| − | Some items can contain subitems. For example, a booking may contain an "invoice item" and an "info item".
| |
| − | | |
| − | Subitems generally work in the same way as their parent items.
| |
| − | | |
| − | Deleting a subitem requires the WRITE scope method, deleting a subitem's parent item requires the DELETE scope method.
| |
| − | | |
| − | '''To add a new subitem to an item, include the subitem without an id.'''
| |
| − | | |
| − | '''''Example: add a new info item to a booking:'''''
| |
| − | [
| |
| − | {
| |
| − | "id": {bookingId},
| |
| − | "infoItems": [
| |
| − | {
| |
| − | "code": "this will create",
| |
| − | "text": "a new info item"
| |
| − | }
| |
| − | ]
| |
| − | }
| |
| − | ]
| |
| − | | |
| − | '''To update an existing subitem, include the subitem's id.'''
| |
| − | | |
| − | '''''Example: update a booking's info item:'''''
| |
| − | [
| |
| − | {
| |
| − | "id": {bookingId},
| |
| − | "infoItems": [
| |
| − | {
| |
| − | "id": {infoItemId},
| |
| − | "text": "this info item will have its text changed"
| |
| − | }
| |
| − | ]
| |
| − | }
| |
| − | ]
| |
| − | | |
| − | '''To delete a subitem, include only the subitem's id.'''
| |
| − | | |
| − | '''''Example: delete a booking's info item:'''''
| |
| − | [
| |
| − | {
| |
| − | "id": {bookingId},
| |
| − | "infoItems": [
| |
| − | {
| |
| − | "id": {infoItemId},
| |
| − | }
| |
| − | ]
| |
| − | }
| |
| − | ]
| |
| − | | |
| − | == Responses ==
| |
| − | All POST requests will have a standard response.
| |
| − | | |
| − | === Structure ===
| |
| − | Responses will be an array containing a number of response items equal to the number of items in the request.
| |
| − | | |
| − | Each response item will contain a "success" boolean field. Success will be false if there were any errors in processing the item.
| |
| − | Note: Success being false does not necessarily mean that nothing has changed.
| |
| − | E.g. if a valid booking with an invalid info item is posted, the booking will be created but the info item will not. Success will be false in this case because there was an error.
| |
| − | | |
| − | A response item may also contain one or more of the following:
| |
| − | *New - contains information about newly created items and subitems. For example, the id of a newly created booking, or the id of a new info item for an existing booking.
| |
| − | *Modified - contains information about modified items and subitems. For example, if the departure date of a booking is changed, this field will have information confirming this change.
| |
| − | *Errors - Contains information about fatal issues with an item or subitem in the request. An error means that an attempt was made to create or change an item or subitem, but that attempt failed.
| |
| − | *Warnings - Contains information about non-fatal issues with an item in the request. A warning means that an item or subitem was created or changed, but, for example, a non-required field had invalid data provided.
| |
| − | *Info - Contains general information about what has happened to the request.
| |
| − | | |
| − | === Order of response items ===
| |
| − | The order of the items in the response will correspond to the order that items were sent in the request.
| |
| − | | |
| − | '''''Example: POST two message for different bookings:'''''
| |
| − | [
| |
| − | {
| |
| − | "bookingId": 1111111,
| |
| − | "message": "a message"
| |
| − | },
| |
| − | {
| |
| − | "bookingId": 2222222,
| |
| − | "message": "a different message"
| |
| − | },
| |
| − | ]
| |
| − | | |
| − | '''''Example: response order for the above request:'''''
| |
| − | [
| |
| − | {
| |
| − | "success": true,
| |
| − | "info": [
| |
| − | {
| |
| − | "message": "information about the message for booking 1111111"
| |
| − | }
| |
| − | ]
| |
| − | },
| |
| − | {
| |
| − | "success": false,
| |
| − | "errors": [
| |
| − | {
| |
| − | "message": "an error about the message for booking 2222222"
| |
| − | }
| |
| − | ]
| |
| − | }
| |
| − | ]
| |
| − | | |
| − | = Prices =
| |
| − | | |
| − | To get price setup rules, include the "includePriceRules" parameter like this
| |
| − | /api/v2/properties?includePriceRules=true
| |
| − | | |
| − | A room can have up to 16 prices.
| |
| − | | |
| − | In the control panel, these can be set under Prices -> Daily Price Setup.
| |
| − | | |
| − | In the API these can be accessed through GET and POST /inventory/calendar
| |
| − | {
| |
| − | "data": [
| |
| − | {
| |
| − | "calendar": [
| |
| − | {
| |
| − | "price1": 100,
| |
| − | "price2": 300,
| |
| − | "price3": 200,
| |
| − | ...
| |
| − | }
| |
| − | ]
| |
| − | }
| |
| − | ]
| |
| − | }
| |
| − | | |
| − | = Examples =
| |
| − | == Authentication ==
| |
| − | === Refreshing a token ===
| |
| − | Request:
| |
| − | <nowiki>curl -X 'GET' \
| |
| − | 'https://api.example.com/v2/authentication/token' \
| |
| − | -H 'accept: application/json' \
| |
| − | -H 'refreshToken: Ea6DftE50aYYRe/qAd9SkQaSmTF6kaLQxH6gtRxO1h10yVC64d4qIj4BGiQOU+y5'</nowiki>
| |
| − | | |
| − | Response:
| |
| − | <nowiki>{
| |
| − | "token": "wEoJHQIwRrLwHqTqAsn0/XjzaZkVk4E8sSDwbRN2HKDlulkt6n7aHQCcvdqfX+y5",
| |
| − | "expiresIn": 3600
| |
| − | }</nowiki>
| |
