---
title: "Get all service order notes"
method: POST
path: "/api/connector/v1/serviceOrderNotes/getAll"
tags: ["Service order notes"]
---

# Get all service order notes

`POST /api/connector/v1/serviceOrderNotes/getAll`

Returns all notes associated with the given service orders. Service orders can be reservations or product orders. Note this operation uses [Pagination](../guidelines/pagination.md) and supports [Portfolio Access Tokens](../guidelines/multi-property.md).
> **Service order:** This is the general name for an order made against a service, which includes both 'stay' service orders, called [Reservations](reservations.md#reservation), and 'product' service orders, which we simply call [Orders](orders.md). Operations such as [Get all service order notes](#get-all-service-order-notes) will accept Reservation IDs or Order IDs as service order identifiers.

## Request body

- ServiceOrderNoteFilterParameters
  - `ClientToken` string, required — Token identifying the client application.
  - `AccessToken` string, required — Access token of the client application.
  - `Client` string, required — Name and version of the client application.
  - `Limitation` Limitation, required — Limitation on the quantity of data returned.
    - `Count` integer, required
    - `Cursor` string, uuid, nullable
  - `EnterpriseIds` string[], nullable — Unique identifiers of the Enterprises. If not specified, the operation returns data for all enterprises within scope of the Access Token.
  - `ServiceOrderIds` string[], required — Unique identifiers of `Service order`. Reservation IDs or Order IDs can be used as service order identifiers.
  - `ServiceOrderNoteIds` string[], nullable — Unique identifiers of `Service order note`. Use this property if you want to fetch specific service order notes.
  - `UpdatedUtc` TimeFilterInterval — When a time interval is used for **filtering** (for example in parameters such as `CreatedUtc.StartUtc` / `CreatedUtc.EndUtc`), the following rules apply: - **Start equals End (equality mode)** If `StartUtc` and `EndUtc` are exactly the same timestamp, the filter is treated as an equality check for that precise moment in time: ``` CreatedUtc == StartUtc ``` This does not represent an interval; only records with `CreatedUtc` equal to that exact instant are returned. - **Start differs from End (interval mode)** If `StartUtc` and `EndUtc` are different, the filter is evaluated as a half-open interval: ``` StartUtc <= CreatedUtc < EndUtc ``` In other words, the start is inclusive and the end is exclusive. Make sure your integration takes inclusive Start / exclusive End behavior of time intervals into account so that no records at the boundaries are omitted.
    - `StartUtc` string, date-time, nullable
    - `EndUtc` string, date-time, nullable
  - `Types` OrderNoteTypeEnum[], nullable — Type of the service order note. Defaults to `["General", "ChannelManager"]`.

## Response `200`

OK

- ServiceOrderNoteResult
  - `ServiceOrderNotes` OrderNote[], required — The collection of service order notes.
    - `Id` string, uuid — Unique identifier of the service order note.
    - `OrderId` string, uuid — Unique identifier of the `Service order` to which the Service Order Note belongs.
    - `Text` string, nullable — Content of the service order note.
    - `Type` 'General' | 'ChannelManager' | 'SpecialRequest' — General ChannelManager SpecialRequest
    - `CreatedUtc` string, date-time, nullable — Creation date and time of the service order note in UTC timezone in ISO 8601 format.
    - `UpdatedUtc` string, date-time, nullable — Last update date and time of the service order note in UTC timezone in ISO 8601 format.
  - `Cursor` string, uuid, nullable — Unique identifier of the last and hence oldest service order note returned. This can be used in [Limitation](https://mews-systems.gitbook.io/connector-api/guidelines/pagination/#limitation) in a subsequent request to fetch the next batch of older service order notes.

## Other responses

- `204` — Server has successfully fulfilled the request and there is no additional information to send back.
- `400` — Error caused by the client app, e.g. in case of malformed request or invalid identifier of a resource. In most cases, such an error signifies a bug in the client app (consumer of the API).
- `401` — Error caused by usage of invalid ClientToken, AccessToken, or you may not have the necessary permission to use the endpoint.
- `403` — Server error that should be reported to the end user of the client app. Happens for example when the server-side validation fails or when a business-logic check is violated.
- `408` — Error caused by heavy request that takes too long to process (typically tens of seconds). To get around this, request data in smaller batches. For more information, see [Request timeouts](https://mews-systems.gitbook.io/connector-api/guidelines/requests#request-timeouts)
- `429` — Error caused by too many requests sent in a given amount of time. Response contains `Retry-After` header indicating how long the user agent should wait before making a follow-up request. For more information, see [Request limits](https://mews-systems.gitbook.io/connector-api/guidelines/requests#request-limits).
- `500` — Unexpected error on the Mews side. This may be due to a software fault. If such a situation occurs, the error will be logged and the development team notified, however you can raise an issue through GitHub on our [documentation repository](https://github.com/MewsSystems/gitbook-connector-api).

---

[API](https://skmtc.net/mews/apis/connector-api.md) · [All operations](https://skmtc.net/mews/apis/connector-api/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/mews/connector-api/versions/81933a8ff730/schema)