Run order reports v3.2

Use the /orders/details endpoint to retrieve reporting and reconciliation data for existing orders across supported travel services from a single endpoint. It provides a consolidated view of order, pricing, payment, commission, attribution, and service-specific booking data without requiring separate requests to each travel service.

The /orders/details endpoint is designed for reporting, synchronisation, and operational workflows across multiple travel services.

Typical use cases include:

• Financial reconciliation and reporting.
• Attribution tracking and performance analysis.
• Synchronising Booking.com order data with internal systems.
• Validating booking, payment, and commission information.
• Retrieving consolidated order information across supported travel services.

Use /orders/details when you need to:

Call orders/details endpoint using one supported filter type.

• Date ranges cannot exceed 7 days.
• created and updated can retrieve orders from the previous 12 months.
• start and end can retrieve orders up to 1 year in the past and 500 days in the future.
• Updates may take up to 2 hours to become available.
• Dates must use ISO 8601 format. See the Data conventions guide for details.

All requests require:

• currency - three-letter ISO 4217 code.

The only exception is requests using page, where the pagination token already preserves the original query context.

You can also include:

• extras — Request additional information. Currently supports payment.
• services — Restrict results to one or more travel services.
• maximum_results — Limit the number of results returned for date-based requests.
• sort.by and sort.direction — Sort results by created or updated, in ascending or descending order.

The services parameter acts as an inclusion filter. Use the optional services field to limit results to specific travel services, for example:

"services": ["accommodations", "cars"]

Default behaviour when services is omitted:

The default behaviour depends on the filter type:

• Identifier-based requests (orders or reservations): if services is omitted, only accommodation orders are returned.
• Date-based requests (created, updated, start, or end): if services is omitted, all travel services available to your account are returned.

To ensure predictable behaviour, explicitly specify services whenever you want to control which travel services are included.

• Do not assume ID-based requests return all travel services.
• Use date-based filters when building:
  • dashboards.
  • reconciliation pipelines.
  • CRM synchronisation.
• Always explicitly set services when you need a reduced dataset in reporting flows.
• Expect different payload shapes depending on the specific travel service returned (e.g., accommodations vs cars).

Scenario: Retrieve payment, pricing, or commission details for known reservations.

{
  "currency": "EUR",
  "reservations": [
    "2321873123",
    "4666773123"
  ],
  "sort": {
    "by": "updated",
    "direction": "descending"
  },
  "extras": [
    "payment"
  ]
}

Scenario: Synchronise newly created accommodation and car bookings for a certain period.

{
    "created": {
      "from": "2025-12-01T02:00:00+00:00",
      "to": "2025-12-07T02:00:00+00:00"
    },
    "currency": "EUR",
    "services": ["cars", "accommodations"],
    "extras": [
      "payment"
    ]
  }

Scenario: Retrieve orders across all travel services available to the partner that end between 5 and 8 June 2026, for synchronisation with an internal CRM system.

{
    "end": {
      "from": "2026-06-05",
      "to": "2026-06-08"
    },
    "currency": "EUR",
    "sort": {
      "by": "updated",
      "direction": "descending"
    },
    "extras": [
      "payment"
    ]
  }

To build incremental sync logic for regularly updating systems:

• Use created.from and created.to to retrieve newly created orders.
• Use updated with small rolling windows (for example, every 30–60 minutes) to detect changes to existing orders.
• Use pagination (metadata.next_page) when processing large result sets.

Each returned order contains common reporting fields regardless of travel service.

When extras includes payment, the response may contain:

• method
• timing
• paid → completed transactions.
• pending→ upcoming or scheduled transactions.

Accommodation payments may also include:

• authorisation_form
• receipt_url

Each returned order contains the travel-service object corresponding to that order. Other travel-service fields are returned as null.

Possible service objects include:

• accommodations
• cars
• flights
• attractions
• taxis (transfers from v3.3)

Taxi orders may contain multiple legs.

• The order-level price, start, end, and status are aggregated across all legs.
• All legs belonging to the same taxi order share the same reservation identifier.
• Each leg has its own leg identifier and lifecycle.
• If different legs have different statuses, the order-level status may be unknown.

{
  "request_id": "req_123",
  "data": [
    {
      "id": "880045112233",
      "affiliate": 111111,
      "status": "booked",
      "start": "2026-12-10T08:00:00Z",
      "end": "2026-12-12T10:00:00Z",
      "currencies": {
        "booker": "EUR",
        "product": "EUR"
      },
      "price": {
        "total_price": {
          "booker_currency": 420,
          "product_currency": 420
        }
      },
      "accommodations": {
          "reservation": "ABC123"
        }
    }
  ],
  "metadata": {
    "next_page": null,
    "total_results": 1
  }
}

{
  "id": "509430129718801",
  "attractions": {
    "reservation": "567890123",
    "name": "Eiffel Tower Guided Tour",
    "location": {"city": "Paris", "country": "fr"}
  },
  "affiliate": 111111,
  "booker": {
    "address": {"city": "Amsterdam", "country": "nl"},
    "email": "janedoe@booking.com",
    "name": {"first_name": "Jane", "last_name": "Doe"},
    "platform": "desktop",
    "telephone": "+100000001",
    "language": "en-gb",
    "travel_purpose": "leisure"
  },
  "commission": {"actual_commission_amount": {"booker_currency": 5.0, "product_currency": 6.0}},
  "currencies": {"booker": "EUR", "product": "EUR"},
  "price": {"commissionable_price": {"booker_currency": 50, "product_currency": 60}, "total_price": {"booker_currency": 55, "product_currency": 66}},
  "status": "booked",
  "start": "2026-07-10T09:00:00+00:00",
  "end": "2026-07-10T12:00:00+00:00",
  "created": "2025-11-28T02:00:00+00:00",
  "updated": "2025-11-28T02:00:00+00:00"
}

{
  "taxis": [
    {
      "leg": "607244787653565",
      "reservation": "916957580",
      "status": "booked",
      "start": "2026-06-05T09:00:00Z",
      "end": "2026-06-05T10:15:00Z",
      "pickup_location": {
        "address": "Amstel 51, 1018 EH Amsterdam, Netherlands",
        "city": "Amsterdam",
        "country": "nl"
      },
      "dropoff_location": {
        "address": "Stationsplein 9, 3511 CE Utrecht",
        "city": "Utrecht",
        "country": "nl"
      }
    },
    {
      "leg": "607244787653566",
      "reservation": "916957580",
      "status": "cancelled",
      "start": "2026-06-08T16:00:00Z",
      "end": "2026-06-08T17:15:00Z",
      "pickup_location": {
        "address": "Stationsplein 9, 3511 CE Utrecht",
        "city": "Utrecht",
        "country": "nl"
      },
      "dropoff_location": {
        "address": "Amstel 51, 1018 EH Amsterdam, Netherlands",
        "city": "Amsterdam",
        "country": "nl"
      }
    }
  ]
}

In addition to the general API error conventions, consider the following conditions when using /orders/details:

Use /orders/details for reporting, reconciliation, and synchronisation.

Use /orders/details/{service} endpoints instead, when you need travel-service-specific functionality, including:

• Managing cancellations.
• Processing modifications.
• Retrieving detailed booking information.
• Supporting customer service workflows.
• Performing service-specific post-booking operations.

These endpoints provide additional information specific to each travel service and are recommended for operational booking management.