# Post booking: Reporting and cancelling Third Party Inventory (TPI) bookings

**Learn how to gerate accurate, efficient reporting on bookings with TPI Net and Commissionable (Sell) rates, and how to cancel TPI bookings if needed.**

## Post booking TPI rates reporting

This section of the guide explains how to identify third-party bookings and distinguish between Net and Commissionable sell rate transactions in your reporting and aims to help you consolidate all relevant booking data, distinguish rate types, and align with Booking.com transactional reports — without the need for manual or event-triggered API calls.

### Reporting endpoints

After a booking is completed, you can use the [orders/details](/demand/docs/open-api/demand-api/orders/orders/details) and [orders/details/accommodations](/demand/docs/open-api/demand-api/orders/orders/details/accommodations) endpoints to retrieve details for all stays transactions, including:

✅ Regular bookings from Booking.com inventory.

✅ Third Party Inventory (TPI) bookings: Both net and sell rates (if activated for your account).

### Using orders/details and orders/details/accommodations

The [orders/details](/demand/docs/open-api/demand-api/orders/orders/details) and [orders/details/accommodations](/demand/docs/open-api/demand-api/orders/orders/details/accommodations) endpoints work together to provide a complete picture of your bookings:

| Endpoint | When to use |  |
|  --- | --- | --- |
| [orders/details](/demand/docs/open-api/demand-api/orders/orders/details) | * To retrieve order-level details for all bookings within a specific period.

 | * Ideal for tracking and consolidating transactions across Booking.com and TPI bookings.
* See [dedicated guidelines](/demand/docs/orders-api/order-details) for best practices.

 |
| [orders/details/accommodations](/demand/docs/open-api/demand-api/orders/orders/details/accommodations) | * To retrieve product-level details for a specific order id or set of orders.

 | * Ideal for a deeper breakdown of individual accommodation products and therefore for operational and financial reporting.
* See [dedicated guidelines](/demand/docs/orders-api/order-details-service) for examples and tips.

 |


Together, [orders/details](/demand/docs/open-api/demand-api/orders/orders/details) and [orders/details/accommodations](/demand/docs/open-api/demand-api/orders/orders/details/accommodations) endpoints give you complete visibility of all bookings — from Booking.com and third-party inventory — and reliable inputs for your reporting processes.

Use the correct Affiliate ID in your requests
* **For net rates, use the dedicated Affiliate ID** provided for your TPI integration in all API calls.
* **For sell rates, use your regular Affiliate ID** in the endpoint calls.


### Identifying TPI rates in the response

Both endpoints response objects include an `inventory` field with details about the source of the product:

| Key fields | Description |
|  --- | --- |
| `third_party_inventory: true` (only in v3.1) | * Confirms the booking comes from a third-party source.

 |
| `inventory.type: sell` or `net` | * Identifies the rate type:
  * ["sell" for Commissionable TPI rates](/demand/docs/accommodations/tpi/sell-how-to)
  * ["net" for Non-commissionable rates](/demand/docs/accommodations/tpi/net-how-to)

 |


Extract these fields and store them in your reporting system to segment bookings accordingly.

### Consolidated reporting for all stays bookings

When you use the [orders/details endpoint](/demand/docs/open-api/demand-api/orders/orders/details) without specifying order IDs, but setting a specific period of time, all your stays bookings are returned, including:

* Direct bookings (from Booking.com inventory).
* TPI bookings with net rates.
* TPI bookings with sell rates.


This helps you maintain a consolidated view of all transactions.

You can apply filtering in your system to focus on specific subsets of data for your reporting needs.

## Suggested reporting flow

We recommend automating scheduled API calls and applying filtering to efficiently retrieve only the bookings relevant for your reporting and reconciliation processes.

### Step 1 - Schedule API calls

Automate API calls to both endpoints based on your reporting needs:

| Action | Frequency | Notes |
|  --- | --- | --- |
| orders/details call | Daily or weekly | Retrieves order-level details. |
| orders/details/accommodations call | Daily or weekly | Retrieves detailed product information. |


> ![Tip on scheduling calls](/assets/genius-bulb.3e13976eeeabd0526f1d76bfb7de5967932211a5ef4afe526a3b0a71a7b02fb0.5e2a7131.png) Adjust the frequency based on your reporting needs — daily is recommended for operational reporting, weekly for financial reconciliation.


### Step 2 - Filter bookings in your requests

For efficient reporting:

* Use the `"end"` parameter in your requests, to retrieve only those bookings that have already finished (based on checkout date) and with status `"stayed"` — this ensures you only report on transactions linked to completed stays.
* Alternatively, filter by creation date to target bookings within a specific period.


Example of orders/details request with "end" parameter:


```json
{
  "end": {
    "from": "2025-03-01",
    "to": "2025-03-07"
  },
  "currency": "EUR",
  "maximum_results": 20,
  "sort": {
    "by": "updated",
    "direction": "descending"
  },
  "extras": [
    "payment"
  ]
}
```

After retrieving the response, filter in your system all results where `third_party_inventory: true` to focus only on TPI bookings.

#### Step 3 - Distinguish between net and sell rates

The `inventory.type` field indicates the rate type for each booking:

* "net" — Net rate transaction (non-commissionable)
* "sell" — Sell rate transaction (commissionable)


Net rate transactions are excluded from your Credit Slip
* Note that **Net rate bookings will not appear in your Credit Slip.**
* Only commissionable bookings (Booking.com regular inventory and sell rate TPI bookings) are included.


### Step 4 - Map bookings to your transactional reporting

Cross-reference booking data from these endpoints with Booking.com’s transactional reports for consistency.

We recommend storing booking details in your internal reporting system, for example:

| Booking ID | Product | Third Party | Rate Type | Credit Slip | Notes |
|  --- | --- | --- | --- | --- | --- |
| 12345 | Hotel X | true | net | No | TPI Net rate booking |
| 12346 | Hotel Y | true | sell | Yes | TPI Sell rate booking |
| 12347 | Hotel Z | false | sell | Yes | Direct booking |


### Step 5 - Recommended automation setup

To minimise manual work and ensure reporting accuracy:

* Trigger API calls to both endpoints after each booking confirmation or based on checking/checkout dates (`started` or `end`).
* Store `third_party_inventory: true` and `inventory.type` in your internal booking database.
* Reconcile daily or weekly with Booking.com’s transactional reports daily or weekly.
* Exclude net rate transactions from Credit Slip reconciliation.


References
* [Orders/details guide](/demand/docs/orders-api/order-details) for instructions, examples and best practices.
* [Orders/details/accommodation guide](/demand/docs/orders-api/order-details-service#/orders/details/accommodations) for examples and tips.
* [Error handling guide](/demand/docs/support/error-handling/about-errors) for common client errors, and tips on solve them.


## Cancelling a TPI booking

TPI bookings follow the cancellation policies defined by the product.

→ Use the standard [/orders/cancel endpoint](/demand/docs/open-api/demand-api/orders/orders/cancel) when allowed.

| **Cancellation policy** | **Cancellation allowed?** |
|  --- | --- |
| [Flexible-free](/demand/docs/orders-api/cancellation-policies#flexible-policies---free-cancellation-until) | ✓ Yes |
| [Non-refundable](/demand/docs/orders-api/cancellation-policies#non-refundable-policies) | ✗ No, attempting will return a [500 error code](/demand/docs/support/error-handling/about-errors#common-http-status-codes). |
| [Partially refundable (special conditions)](/demand/docs/orders-api/cancellation-policies#partially-refundable-policies---special-conditions) | ✗ Not supported. |


![genius-bulb](/assets/genius-bulb.3e13976eeeabd0526f1d76bfb7de5967932211a5ef4afe526a3b0a71a7b02fb0.5e2a7131.png) Always check the cancellation policy before attempting cancellation.

> * In accommodations/availability response under `policies.cancellation.type`
* In orders/preview response looking at the cancellation schedule (`from`).



References
* [Cancellation policies](/demand/docs/orders-api/cancellation-policies) – Learn how to interpret and display cancellation conditions.
* [Cancel an order](/demand/docs/orders-api/cancel-order) – Get guidance on how to cancel a booking and handle refunds if needed.


## Next steps

Learn more about how TPI works across different business models: