> ## Documentation Index
> Fetch the complete documentation index at: https://docs.d-edge.com/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> This site documents the D-EDGE APIs for technology partners (web agencies, OTAs, PMS and RMS vendors, booking and CRM tools). It is written for developers integrating with hotels that use the D-EDGE platform.
> Seven APIs, grouped by domain. Connectivity: Channel Manager API (distribute a hotel's inventory to your channel and send bookings back). Pricing & Availability: Best Price API (best offers to highlight), Quotation API (all bookable offers for a stay), Daily Rates API (daily availability between two dates). Booking: Booking Engine API (a hotel's full direct booking funnel), Gift Shop API (gift vouchers from catalogue to payment). Guest Management: CRM API (guest profiles).
> Pick the API by the need: to display prices, use the Best Price API or the Daily Rates API; to quote a specific stay, use the Quotation API; to book, use the Booking Engine API; to sell gift vouchers, use the Gift Shop API; to manage guest profiles, use the CRM API; to receive hotel inventory and send bookings back as a distribution channel, use the Channel Manager API.
> Base URLs, hotel identifiers, and credentials are delivered by the D-EDGE partnership team during onboarding. Do not invent base URLs, endpoints, parameters, or example credentials that do not appear on these pages.
> Authentication differs per API: OAuth 1.0 for Best Price, Quotation, Daily Rates, and Booking Engine; an X-API-KEY header for Gift Shop; OAuth 2.0 client credentials for CRM; partner-defined credentials carried in the XML message for the Channel Manager API. Read each API's Authentication page before writing code.
> A mock environment returns realistic but fictitious data without credentials. The Postman and Insomnia collections on the API collections page target it by default. Use it for exploration and tests, never for production traffic.
> Use the official names exactly: D-EDGE, D-EDGE platform, Channel Manager API, partnership team. Do not use Back Office or Extranet.
> Each API has a Changelog page. Check it for the current behaviour before relying on an older answer. For questions these pages do not answer, direct the reader to the Contact us page.

# API collections

> Ready-to-run requests for Postman and Insomnia

## Download a collection

Every collection here is preconfigured to call the [mock environment](/overview/resources/glossary.md#mock-environment) with no credentials. Re-download after major content updates.

###  API reference

Every endpoint of this portal and every pricing API use case, as ready-to-run requests, in one folder per API, seven in all. The mock environment returns realistic but fictitious data, so you can explore every request and response before you receive your access details.

> **D-EDGE Docs: API reference**
>
> Postman collection, version 1.1 

[Open](/api-collections/d-edge-docs.api-reference.postman.json)

> **D-EDGE Docs: API reference**
>
> Insomnia collection, version 1.1 

[Open](/api-collections/d-edge-docs.api-reference.insomnia.json)

> **Before you run it**
>
> Four of the seven folders need more than a Send.
>
> **Run the Booking Engine, Gift Shop, and CRM folders in order.** Their requests chain: each one reuses the identifiers the previous one returned, so a request opened on its own has nothing to work with. On the CRM API, once the credentials are set, both tools request and refresh the OAuth 2.0 token themselves from `crmApi.tokenUrl`, so there is no token request to run.
>
> **Decide what the Channel Manager folder talks to.** There the collection plays D-EDGE, so its requests target `channelManagerApi.yourBaseUrl`, the mock by default and your own server once you set it. Push bookings is the one call you make to D-EDGE rather than the other way round, and its credentials arrive later than the rest, during certification.
>
> *In Postman, the variables prefixed with `_` fill themselves as you run those three folders in order: leave them empty.*

> **Variables to fill**
>
> You only need these to call the live API: against the mock the collection runs on the values it already carries. D-EDGE delivers your credentials after the partnership agreement, during the build step of the [integration journey](/overview/get-started/your-integration-journey.md).
>
> | Variable | What it is |
> | - | - |
> | `common.oauth1.consumerKey` | OAuth 1.0 consumer key |
> | `common.oauth1.consumerSecret` | OAuth 1.0 consumer secret |
> | `common.oauth1.token` | OAuth 1.0 token |
> | `common.oauth1.tokenSecret` | OAuth 1.0 token secret |
> | `common.hotelId` | Identifier of the property to query |
> | `common.groupId` | Identifier of the group to query |
> | `common.currency` | Default currency for responses, for example EUR |
> | `channelManagerApi.baseUrl` | Base URL of the D-EDGE Push bookings endpoint. Mock by default; live base URL provided by D-EDGE. |
> | `channelManagerApi.yourBaseUrl` | Base URL of the endpoints you host for the Channel Manager API. Mock by default, standing in for your server; set it to your own server to test your endpoints. |
> | `channelManagerApi.login` and `channelManagerApi.password` | The credentials you defined for D-EDGE to call your endpoints, sent as Basic Auth on every request and also inside the XML on the POST requests. Prefilled with test values for the mock. |
> | `channelManagerApi.hotelCode` | The hotel code on your platform used by the requests. `1234` for the mock. |
> | `channelManagerApi.pushLogin` and `channelManagerApi.pushPassword` | The Push bookings credentials issued by D-EDGE. Not needed for the mock. |
> | `bestPriceApi.baseUrl` | Base URL of the Best Price API. Mock by default; live base URL provided by D-EDGE. |
> | `quotationApi.baseUrl` | Base URL of the Quotation API. Same pattern. |
> | `dailyRatesApi.baseUrl` | Base URL of the Daily Rates API. Same pattern. |
> | `bookingEngineApi.baseUrl` | Base URL of the Booking Engine API. Same pattern. |
> | `bookingEngineApi.engineId` | Booking engine identifier, provided by D-EDGE |
> | `bookingEngineApi.selectedHotelId` | Identifier of the hotel used by the Booking Engine requests |
> | `bookingEngineApi.bookingReference` | Reference used by the Booking endpoints |
> | `giftShopApi.baseUrl` | Base URL of the Gift Shop API. Same pattern. |
> | `giftShopApi.apiKey` | API key of the Gift Shop API, sent as the `X-API-KEY` header. The other credentials do not apply to this API. |
> | `crmApi.baseUrl` | Base URL of the CRM API. Same pattern. |
> | `crmApi.tokenUrl` | Token endpoint of the D-EDGE CRM ID server, provided with your credentials |
> | `crmApi.clientId` | OAuth 2.0 client ID of the CRM API |
> | `crmApi.clientSecret` | OAuth 2.0 client secret of the CRM API |
> | `crmApi.entityId` | Identifier of the entity whose guest profiles you manage, a UUID |
> | `crmApi.mergedGuestId` | Merged profile that Unmerge a guest splits back apart, taken from the end of the merge task's `result.rid` |
> | `common.mockApiKey` | Key of the shared mock environment, sent as the x-mock-api-key header. Prefilled, leave unchanged. |

> **Versions**
>
> **13 October 2026**
>
> Version 1.1
>
> The Best Price mock now answers like the updated API. Each entry of Rates, Rooms, and Hotels (Arrivals) carries the `behaviour` it was computed for. Rates and Rooms entries also carry `availability`. The Hotels (Arrivals) request now describes its result as the best price per hotel over a date range.
>
> **18 September 2026**
>
> Version 1.0
>
> Six CRM API requests join both files: compute merge confidence, read a task, unmerge a guest, create a segment, update a segment, and browse bookings. The merge and the confidence computation chain into the task read, which follows them until they end.
>
> **16 September 2026**
>
> Version 0.5
>
> The collection is renamed D-EDGE Docs: API reference, and carries its version number from now on: `info.version` in Postman, the workspace description in Insomnia.
>
> **9 September 2026**
>
> Version 0.4
>
> The Channel Manager API folder joins both files: thirteen requests reproducing the examples of the reference pages, the collection playing D-EDGE.
>
> **6 August 2026**
>
> Version 0.3
>
> Every Gift Shop endpoint joins both files as a ready-to-run request on the mock environment.
>
> **10 June 2026**
>
> Version 0.2
>
> Every Booking Engine endpoint joins both files, in funnel order: each request reuses the identifiers returned by the previous one.
>
> **2 June 2026**
>
> Version 0.1
>
> Both files call the mock environment by default, so the Best Price, Daily Rates, and Quotation requests run with no credentials.

###  Channel Manager API test scenarios

The [test scenarios](/channel-manager-api/get-certified/test-scenarios.md) D-EDGE runs to certify a Channel Manager API integration, as ready-to-send requests in ten folders. There is one folder per interface you host, a refusal folder next to three of them, and one per price model. The collection plays D-EDGE, calls those four endpoints, and checks the response each scenario expects.

> **D-EDGE Docs: Channel Manager API test scenarios**
>
> Postman collection, version 1.0 

[Open](/api-collections/d-edge-docs.channel-manager-api-test-scenarios.postman.json)

> **D-EDGE Docs: Channel Manager API test scenarios**
>
> Insomnia collection, version 1.0 

[Open](/api-collections/d-edge-docs.channel-manager-api-test-scenarios.insomnia.json)

> **Before you run it**
>
> Out of the box this collection can run entirely green and prove nothing: two settings decide whether a result means anything.
>
> **Point it at your own server.** Fresh from the import the four URL variables target the mock environment, which answers success to everything, including the three refusal folders that are meant to fail. Set them to your test environment before you read any result.
>
> **Give it your room and rate codes.** Run Get hotel and read your own response: it declares your room types and your rates, and every Planning updates message the collection sends addresses them by those codes. Copy the ones you want to certify with into the variables below. Your test hotel needs at least three room types and three rates in total, one room carrying at least two rates, because the scenarios reference that shape.
>
> *The collection does not read those codes back from your response on purpose: a rule that took whichever room came first would run green against the wrong shape.*

> **Variables to fill**
>
> Everything below except `mockApiKey` describes your own platform. The values shipped with the collection are the ones the mock uses.
>
> | Variable | What it is |
> | - | - |
> | `getHotelUrl` | URL of your Get hotel endpoint. Mock by default. |
> | `planningUpdatesUrl` | URL of your Planning updates endpoint. Mock by default. |
> | `getBookingsUrl` | URL of your Get bookings endpoint. Mock by default. |
> | `confirmBookingsUrl` | URL of your Confirm bookings endpoint. Mock by default. |
> | `login` | The login you defined for D-EDGE, sent as Basic Auth and inside the XML of the POST messages. |
> | `password` | The password you defined for D-EDGE. |
> | `wrongPassword` | A password your platform must reject, sent by the scenarios that check a refusal. Any value other than your password. |
> | `hotelCode` | The code of your test hotel on your platform. |
> | `currency` | The currency your Get hotel response declares for the test hotel. |
> | `room1` | Code of a room type carrying at least two rates. |
> | `room1rate1` | Code of the first rate of room1. |
> | `room1rate2` | Code of the second rate of room1. |
> | `room2` | Code of a second room type. |
> | `room2rate1` | Code of a rate of room2. |
> | `room3` | Code of a third room type. |
> | `room3rate1` | Code of a rate of room3. |
> | `room3rate2` | Code of a second rate of room3, or the same code again when it has one rate. |
> | `month1` | First month of every date range of the collection, YYYY-MM. Set it to the month you want to test; the ranges use days 01 to 28. |
> | `month2` | The month after month1, YYYY-MM: the longer ranges end there. |
> | `farMonth` | The month the long-range scenarios (PU-02, PU-04, PU-17) reach, YYYY-MM. Keep it within the horizon your platform stores. |
> | `pastDate` | A day in the past, YYYY-MM-DD, where the range of PU-03 starts. |
> | `from` | Start of the Get bookings window for GB-02 and GB-05, UTC. Move it to a window that holds bookings on your test hotel. |
> | `to` | End of that window, UTC. |
> | `bookingId` | Identifier of a booking your Get bookings endpoint returned, acknowledged by the Confirm bookings scenarios. |
> | `mockApiKey` | Key of the shared mock environment, sent as the x-mock-api-key header. Ignored by your own server. Leave unchanged. |

> **How to run it**
>
> **1. Run the folders in order**
>
> Run the ten folders top to bottom with the Collection Runner in Postman or the Runner in Insomnia, or send the requests one by one. Among the three price folders, run the one your Get hotel response declares and leave the two others. Leave out the scenarios your platform does not support. Each one that depends on a capability carries a marker on the [test scenarios](/channel-manager-api/get-certified/test-scenarios.md) page, and your [questionnaire](/channel-manager-api/get-certified/questionnaire.md) is where you declared which ones you meet.
>
> **2. Read the results**
>
> Each request carries the four [checks every response must pass](/channel-manager-api/get-certified/test-scenarios.md#checks-on-every-response), named after the scenario it plays: `PU-F3 answers 200 OK`, `PU-F3 answers within 5 s`, `PU-F3 returns <failure> of type 4`. A red line points at the row below to read. Fix, run again, and [hand over your endpoints](/channel-manager-api/get-certified/certification-steps.md) when everything is green against your test environment.

> **Versions**
>
> **16 September 2026**
>
> Version 1.0
>
> First version: the phase one scenarios of the Test scenarios page, 63 requests in ten folders, four checks per request, dates in two months you choose.

## How to import

Every collection on this page imports the same way and answers from the mock environment until you change its variables. Re-import the downloaded file at any time to return to the mock configuration.

**Postman**

**1. Import the file**

In Postman, go to **File > Import** and add the JSON file.

**2. Run a request**

Open any request and click **Send**. The collection calls the mock environment by default, so you get a response with no further setup.

**3. Fill the variables**

Select the collection, go to the **Variables** tab, and fill what the Variables to fill accordion of that collection lists above. Click **Save**.

**Insomnia**

**1. Import the file**

In Insomnia, go to **Application > Import**, select **From File**, and add the JSON file.

**2. Run a request**

Open any request and click **Send**. The collection calls the mock environment by default, so you get a response with no further setup.

**3. Fill the variables**

Open the workspace, select the **Base Environment**, and fill what the Variables to fill accordion of that collection lists above. Click **Done**.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.