> ## 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. # Best practices > Clean profiles, duplicates, and personal data The CRM API holds a hotel's guest data, so the quality of what you write matters as much as the reliability of how you call it. These patterns keep profiles clean, searches fast, and personal data handled with care. ## Writing profiles ### Send the real source with every attribute Each attribute carries a `from` field naming who provided the information: `agent`, `guest`, `pms`, or `system`. Set it to the actual origin of the data you send rather than a constant: the profile's value comes from knowing where each piece of information came from. ### Prefer differential updates Reach for `PATCH` when you add information: array attributes append instead of being replaced, so you never erase an email or a phone another source contributed. Use `PUT` when you intend to override attributes, and `"strict": true` only when you intend to rebuild the whole profile: it overrides everything, including the attributes absent from your payload. ### Check what an update stored An attribute whose value the API rejects is dropped without changing the status code, and the response carries no body, so a `200 OK` tells you nothing about what landed. When the write matters, follow it with **Get a guest** and compare. Validate values against the documented enums on your side before sending them, since that check is the only one you control. See [Responses](/crm-api/build/guidelines/responses.md). ## Finding guests ### Search for screens, browse for volume **Search guests** fits interactive screens: it returns the first matches of a query, up to 100, and each document carries the guest plus the booking when the query touches stay criteria. It is not suitable for large result sets. To walk through a high volume of guests, use **Browse guests**, which returns an `afterKey` cursor you send back to get the next page. ### Count before you pull **Count guests** returns the number of guests matching a query, with an `accurate` flag saying whether the number is exact or an estimate. Run it before a heavy export to size the work, or to display a figure without fetching a single profile. ### Build queries from the listed pairs Which operators a field accepts depends on the field: a date takes the day keywords, a text field the contains operators, a number the comparisons. Build each criterion from the pairs the [Search criteria](/crm-api/build/guidelines/search-criteria.md) page lists, and validate them on your side before sending, as you would an enum value. ## Duplicates ### Score before you merge **Compute merge confidence** measures how close a set of profiles is, on the same scale as the merge threshold, and hands the score back through its task. Run it first when the decision is not obvious, and keep the score: it is what tells you whether a threshold of 75 is right for your data. ### Set the threshold to match your tolerance **Merge guests** compares all the listed guests and merges them only when the similarity threshold is reached for every comparison (the default is 75). Raise the threshold when you would rather leave a duplicate in place than merge two different people. The merged profile keeps the identifiers of its source profiles in `composedWith`, and **Unmerge a guest** splits it back apart, so a merge is recoverable. ### Wait for the task before reading the result Both calls run in the background and answer with a `location` header pointing at a task. A `200` on the call itself means the work was accepted, nothing more: read the task until its `status` settles before treating the merge as done. See [Responses](/crm-api/build/guidelines/responses.md). ### Expect redirects on merged guests After a merge, reading a source guest returns the merged profile. Pass `redirect=false` to read the original instead, and `expand=true` to inspect the source profiles behind a merged one. ## Personal data ### Honour the opt-out flags A profile carries an `optedOut` flag per communication channel, each one absent until something records it. Read them before sending any communication to a guest, and handle the absent case explicitly. Write them when a guest changes their preferences on your side, so every system connected to the entity sees the same choice. ### Anonymise instead of deleting Guest profiles are anonymised rather than deleted: **Anonymise a guest** is the way to honour a guest's request to have their data removed. Trigger it from your own privacy workflow so the profile is anonymised in the CRM at the same time as in your systems. ### Store identifiers, not copies Keep the guest identifier and the entity identifier on your side and read the profile when you need it, rather than replicating personal data in your own database. Every copy you avoid is one less store to protect and purge. ## Resilience ### Retry transient errors with care Retry transient failures (network blips, `408`, and occasional `5xx`) on `GET` calls with exponential backoff. **Create a guest** is not idempotent: retrying it can create a duplicate profile, so when a create times out, search for the guest before sending the call again. ### Plan for slow or unreachable calls Decide upfront how long your interface waits for a response and what it shows past that point. Make the choice deliberately rather than letting the network decide. ### Log the error details When a call fails, capture the `code`, `message`, and `data` fields from the error body in your logs. They let the partnership team pinpoint the failure when you report it. ### Tell us before a major launch If you are rolling out a campaign likely to multiply your normal volume by ten or more, [contact us](/overview/resources/contact-us.md) a few days ahead. We will watch the launch window with you and flag anything unusual the moment it appears. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.