Search

search resolves a name — “the Sunny Loft”, a guest’s surname, a lock’s name — to the ID of the record it belongs to, when you don’t yet know which typed operation to call. One query covers properties, property groups, reservations, devices, tasks, property elements and members. Every field is listed on the operation’s page in the API Reference.

Operation	Request	Permission
`search`	`GET /search`	`view_dashboard`

Paths are relative to your region’s base URL, for example https://api-us.suiteop.com/api/v1. See Authentication for permissions. On the MCP server the same operation is the search tool.

Use it to find an ID, then switch to the typed operations: getProperty, getReservation, listTasks and the rest filter, page and return whole records, which search does not.

Searching

curl -G "https://api-us.suiteop.com/api/v1/search" \
  --data-urlencode "query=sunny loft" \
  --data-urlencode "entityTypes=property" \
  --data-urlencode "entityTypes=reservation" \
  -H "Authorization: Bearer sk_live_your_key_here"

Parameter	Notes
`query`	Required, 1 to 200 characters. Words match as prefixes, and close misspellings still match for every type except members. Fewer than 2 characters, after trimming, returns no results.
`entityTypes`	Optional. Any of `property`, `property_group`, `reservation`, `device`, `task`, `element` and `user`. Repeat the key for several types; a comma-separated list is rejected with `400`. Omit it to search every type.
`limit`	Optional, 1 to 50, default 20. The cap is across all types combined.

{
  "data": {
    "items": [
      {
        "searchIndexId": "6f1c2a8e-0b4d-5e3f-9a7c-1d2e3f4a5b6c",
        "entityId": "3a9d7e21-5c4b-4f8a-b1e2-9c0d8f7a6b5e",
        "entityType": "property",
        "name": "Sunny Loft",
        "subtitle": "12 Harbour Street",
        "ownerType": null,
        "ownerId": null,
        "memberId": null
      }
    ],
    "total": 1
  },
  "meta": { "requestId": "3f1c9a52-…" }
}

The response is not paginated: there is no offset and no meta.pagination, and the results are in data.items, not data. total is the number of items in this response, not the number of matches in your organization. Narrow query or entityTypes rather than raising limit to find a record that is missing.

Reading results

entityId is the ID to pass to the typed operation for that entityType — for example getProperty for property, getDevice for device, getTask for task.
user results carry the person’s user ID in entityId, which member operations don’t accept. memberId on the same result is the membership ID that getMember and the other member operations take. memberId is null for every other type.
element results are property elements. An element has no read operation of its own. When ownerType is property, pass ownerId as the propertyId of listPropertyElements to list that property’s elements. An element shared at the group level (ownerType property_group) has no public list operation, so entityId and ownerId are all the API returns for it. Elements also match on serial number, make and model. Every other type returns ownerType and ownerId as null.
searchIndexId is stable for a given record, so you can use it to de-duplicate results across calls. It is not an ID any other operation accepts.
Results are grouped by type, the type with the strongest match first, and best match first within each type. When several types match, the limit is shared between them, so a large number of reservation matches can’t push out the one property you meant.

Scope and freshness

Results are read from live data, so a record can be found as soon as it exists.
Properties, groups, reservations, devices, tasks and elements are limited to the properties your key or OAuth grant can access. Member results are not property-scoped.
Member matching is literal: a misspelled name finds nothing.