The current rates/getall API call does not bring up the Rate Description and Rate Segment.

Regarding the Segment: Arguably, someone could link the rates response to the reservations response and grab the Segment of the rate from the reservations it's linked to. The issue however is that once a rate is applied to a reservation, the user can go to the reservation and change the segment field, which leads to different segments on the reservation level and the corresponding rate level.

Regarding the Descriptions: It would be useful if we can have the Rate Descriptions in the rates/getall API response for reporting.

Mews now send and API call to Hotek Key cutter for only one key at a time, if you want to create multiple keys at a time it send it separately and not in one command. We check with Hotek and they confirmed to us that Mews send multiple keys creating in different commands and not in one command. This cause a lot of irritation with people at the reception, because it's not clear when the first key is created and when they need to put the second key on the card reader. Allowing duplicate keys is not and option as lost card or stolen card are not deleted from the system and still has access to the room creating a security issue.

Is there any way we could have an "Orders/GetAll" API call? The reason for this is the ability to grab notes stored in an order which is not linked to a reservation. Please note that those notes are different from the notes existing in the respective accounting items.

These standalone orders can be found in the bottom section (Orders) of a customer dashboard in the front end, along with their Notes we want, which currently cannot be extracted through the Mews API.

This ORDERS dataset being taken from such an API call would also be useful for reporting since the accounting items call already has an "OrderId" field.

Let's take for an example the hotel "Hôtel Golf Château de Chailly".
After calling the "rules/getAll" and "products/getAll" we see that the product "6c5ed799-2e8a-4a18-8325-ac7a0086a886" is applied for "ResourceCategoryType" equals to "Room" and "Suite". But it's not added to the price displayed on the booking engine, for example, for tarif "7c58c0e7-64f2-41d6-aaff-ac6f00c31da1" and room "7599d179-e235-4894-9310-ac6f00c320ff".

You colleague explained us that this product is the city tax. And as this product has the option Exclude price from offer so only the price of the room will appear on the distributor.

But how can we know if the product has this option (Exclude from offer) or not? By calling "products/getAll" and "rules/getAll" we don't receive any field which inicates it. Your colleague also confirmed that this information is not returned in your API response at the moment. So please include it.

When a POS is sending a product to post in Mews, the product must have an accounting category in the POS and Mews. If there is no accounting category set in POS, then the item as well as any other items in the Cart are not posted in Mews.

In other POS systems, if an accounting category is accidentally not created in the POS, the PMS will accept the product as well as the full cart of items but place the item in a "None" category or "Uncategorized", allowing the charge. Similar to what Channel Managers do with Mews. If a rate code was built in CM, but not in Mews, the reservations is still pushed into Mews but the rate code and market segment is changed to the default rate code and market segment used by the property.

This is often overlooked during a testing phase as the assumption is that like other PMS systems (Opera, OnQ) respond the same if an accounting category has not been set in the POS.

There are some endpoints (for example: the /reservations/search endpoint) that allow us to query certain objects like reservations that were created or modified in a certain time interval. If the time interval causes Mews to fetch too many objects, it will return a 408. This can be less straightforward for the caller as the caller does not know in which time interval most creations/modifications happened and the caller will thus keep calling the endpoint until the time interval is finally small enough for the request to succeed. As you can see, this can/will result in several consecutive failing calls which results in a longer wait time for the caller (you need to wait for the response to know if the time interval is ok and if not, you actually waited for nothing) and several unnecessary queries in your database as the result isn't used.

To overcome this, we would like to suggest adding pagination to your endpoint. Pagination means that you will only return X objects in the response (lowering the impact on your database) and let the user know if there are more objects that match the time interval filter so they can crawl the next page. This means that each call be the caller will also be successful and the wait wasn't for nothing