# Getting started

This page covers authentication, authorization, rate limiting, and versioning for the RtB API.

## Authentication

As with any other Connectivity API, you can use [machine account based authentication](/connectivity/docs/authentication#machine-account).

## Authorization

RtB API requires the same property permissions as the [Reservations API](/connectivity/docs/reservations-api/reservations-overview).

## Rate limiting

We apply rate limiting in the RtB API, please see [connectivity rate limiting](/connectivity/docs#rate-limiting) for more information.

## Versioning

Use the `X-Booking-Api-Version` header to select the API version, which in turn selects the RtB
contract your integration follows.

```http
X-Booking-Api-Version: 2.0.0
```

If you omit the header, the API defaults to `1.0.1`.

### API versions

RtB is offered as two **major versions**, each with a different inventory behavior:

* **Version 1.x (INQUIRY flow).** A pending request is informational and
does *not* hold inventory. Block availability only when the request becomes `BOOKED`.
* **Version 2.x (RTB flow).** Each request carries a `requestType` field that determines its
inventory behavior. For `RTB` requests, a pending request *holds* inventory, so you block and
release provider-side availability based on the request status. For `INQUIRY` requests, the
behavior matches version 1.x: the pending request is informational and does *not* hold inventory.
This is the model described in the [RtB 2.0](/connectivity/docs/request-to-book/rtb-2.0/overview) section.


Pick the version that matches your integration via the version header. Incremental features (such as
[withdrawal](/connectivity/docs/request-to-book/withdrawal)) ship to both major versions independently, so each has its own version history.

### Version history

| Version | Major version | What it adds |
|  --- | --- | --- |
| `1.0.1` | 1.x (INQUIRY flow) | Base RtB. Used by default when no version header is sent. |
| `1.1.0` | 1.x | [Withdrawal](/connectivity/docs/request-to-book/withdrawal) (`WITHDRAWN_PENDING_APPROVAL` request status). |
| `2.0.0` | 2.x (RTB flow) | The `requestType` field, status-based availability holds, the `FAILED_TO_PROCESS` status, and payment pre-authorization with VCC settlement. See [RtB 2.0 API changes](/connectivity/docs/request-to-book/rtb-2.0/api-changes#api-versioning). |
| `2.1.0` | 2.x | [Withdrawal](/connectivity/docs/request-to-book/withdrawal) (`WITHDRAWN_PENDING_APPROVAL` request status). |


## Request headers

Include the following headers in your RtB API requests.

| Header | Description | Type | Required |
|  --- | --- | --- | --- |
| `Authorization` | [JWT access token.](/connectivity/docs/token-based-authentication) Example: `Bearer {JWT}` | String | Required |
| `X-Booking-Api-Version` | [API Version](/connectivity/docs/request-to-book/technical-overview#versioning) | String | Required |


## Messaging

For pre-reservation messaging via [Messaging API](/connectivity/docs/messaging-api/understanding-the-messaging-api), see [pre-reservation messaging](/connectivity/docs/request-to-book/pre-reservation-messaging) section.

This requires implementing the Messaging API.