---
title: "Process reservation"
method: POST
path: "/api/connector/v1/reservations/process"
tags: ["Reservations"]
---

# Process reservation

`POST /api/connector/v1/reservations/process`

Marks a reservation as `Processed` (= checked out). Succeeds only if all processing conditions are met (the reservation has the `Started` state, balance of all reservation members is zero etc). Note this operation supports [Portfolio Access Tokens](https://mews-systems.gitbook.io/connector-api/concepts/multi-property).
### Conditions
- Reservation has already been checked in.
- Reservation isn't alredy in `Processed` state.
- Reservation can't be checked out sooner than last day of planned stay.
- The companion profiles of reservation are complete (details can be found in error message).
- If `AllowOpenBalance` set to `false`, all bills have to be closable (items on bills are either paid by current customer, or set to be paid by other customer). With `CloseBills` option set to `true` they can be automatically closed, when set to `false` they must be closed manually.
- If `AllowOpenBalance` set to `true`, `Notes` must be filled in.

## Request body

- ReservationProcessingParameters
  - `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.
  - `EnterpriseId` string, uuid, nullable — Unique identifier of the enterprise. Required when using [Portfolio Access Tokens](https://mews-systems.gitbook.io/connector-api/concepts/multi-property), ignored otherwise.
  - `ReservationId` string, uuid, required — Unique identifier of the reservation to process.
  - `CloseBills` boolean, nullable — Whether closable bills of the reservation members should be automatically closed.
  - `AllowOpenBalance` boolean, nullable — Whether non-zero consumed balance of all reservation members is allowed.
  - `Notes` string, nullable — Required if AllowOpenBalance set to true. Used to provide reason for closing with unbalanced bill.

## Response `200`

OK

- Unit

## 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/revisions/4bf95cbc375f/schema)