> ## 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.

# Requests

> Entity scoping, sourced attributes, and differential updates

The CRM API accepts JSON requests over HTTPS only. Every request carries the `Authorization` header, as described on the [Authentication](/crm-api/build/guidelines/authentication.md) page.

## Entity scoping

Almost every route lives under `/api/guestprofile/entities/{entity_id}/`: the entity is the workspace that holds the guest profiles, and its identifier is a UUID delivered by D-EDGE with your credentials. A token can cover one or several entities.

Two routes sit elsewhere. **Browse bookings** lives on the bookings service, under `/api/bookings-manager/entities/{entity_id}/`, and **Read a task** is not scoped to an entity at all, at `/api/guestprofile/tasks/{task_id}`. Both take the same token.

## Methods

| Method | Use |
| - | - |
| `GET` | Read a guest, a segment, the segment list, or a task |
| `POST` | Create a guest or a segment, search, count, browse, and run profile actions (anonymise, merge, unmerge) |
| `PUT` | Override the attributes of a guest with the request payload |
| `PATCH` | Update a guest differentially, or update a segment |
| `DELETE` | Delete a segment |

## Headers

| Header | Value |
| - | - |
| `Authorization` | `Bearer` followed by your token, see [Authentication](/crm-api/build/guidelines/authentication.md) |
| `Content-Type` | `application/json` (for `POST`, `PUT`, and `PATCH`) |

## Sourced attributes

Guest attributes are not bare values: each one pairs a `value` with a `from` field naming who provided the information (`agent`, `guest`, `pms`, or `system`).

```json theme={null}
{
  "firstname": {"value": "Martin", "from": "guest"},
  "emails": [
    {"value": {"email": "guest@example.com"}, "from": "system"}
  ],
  "loyalty": {
    "value": {"program": "hotelrewards", "id": "123456789", "status": "gold"},
    "from": "pms"
  }
}
```

The shape of `value` follows the attribute: a plain string for `firstname` and `languages`, an object for the structured ones. `emails` is the one to watch, since its value is an object carrying an `email` key rather than the address on its own.

Attributes that accept several values (`languages`, `nationalities`, `emails`, `phones`, `notes`, `addresses`) are arrays of sourced values; on all of them but `notes`, one entry can carry `preferred: true`.

## Full and differential updates

The API offers two update styles on a guest:

* **`PUT` (Update)**: each attribute present in the payload overrides its stored value. Add `"strict": true` to override the whole profile, including the attributes absent from the payload.
* **`PATCH` (Differential update)**: array attributes append the values from the payload instead of replacing them.

On both, an attribute object can carry update markers next to `from` and `value`:

| Marker | Effect |
| - | - |
| `_delete: true` | Remove the attribute or the array entry |
| `_index` | Target an existing entry of an array attribute |
| `preferred: true` | Mark an array entry as the preferred one |

## Search queries

The search, count, and browse endpoints share one query model, **Browse bookings** included: a `logic` operator (`AND` or `OR`) over groups of `criteria`, each criterion carrying a `field`, an `operator`, and a `value`, all three as strings.

```json theme={null}
{
  "query": {
    "logic": "AND",
    "criteria": [
      {
        "logic": "OR",
        "criteria": [
          {"field": "country", "operator": "=", "value": "FR"},
          {"field": "nationality", "operator": "=", "value": "FR"}
        ]
      }
    ]
  }
}
```

The fields a criterion can target, and the operators each one accepts, are listed on the [Search criteria](/crm-api/build/guidelines/search-criteria.md) page: which operators a field accepts depends on the field. Criteria combine guest attributes, stay attributes, and figures computed from a guest's history, which is what lets a single query mix who the guest is with how they stay.

**Search** returns the first matching documents, up to 100, and is not suited to large result sets. **Browse** pages through large volumes: send `limit` in the body, then send back the `afterKey` the response returns to get the next page. See [Best practices](/crm-api/build/best-practices.md) for choosing between the two.

**Browse bookings** paginates differently: send `limit` and `offset`, and the response carries a `total` so one call sizes the work and returns its first page.

## Idempotency

Read calls (`GET`) are safe to retry: they never change state. `PUT` updates are idempotent: repeating one leaves the profile in the same state. `PATCH` is **not**: array attributes append on every call, so a retried `PATCH` can duplicate an email or a phone. `POST` calls are not idempotent either: retrying **Create a guest** can create a duplicate profile. **Delete a segment** is idempotent: once the segment is gone, repeating the call changes nothing.


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