Skip to main content
The CRM API accepts JSON requests over HTTPS only. Every request carries the Authorization header, as described on the Authentication 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

​
Headers

​
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).
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:

​
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.
The fields a criterion can target, and the operators each one accepts, are listed on the Search criteria 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 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.