Skip to main content

Hey Mews Community!

We had the pleasure of hosting another fantastic Community Panel Series today, and it was an insightful session! A big thank you to our expert panelists: @RURURUDS@Mariusz Siwkowski , @Hendrik Renken for sharing your valuable insights and experiences. 🎉

And a special shoutout to @Ben Hohnen, our solution architect, for expertly moderating this discussion and and our Product Manager @sylvia.tang for adding her insightful questions! 🌟

Our panelists shared their thoughts on:

  • How to select and integrate new solutions within Mews.
  • Leveraging Mews Open API to build custom solutions and unlock new opportunities.
  • Practical tips for creating a seamless tech stack that aligns with business goals.

📣 There were four open questions during the session—please find them answered below.

We encourage you to watch the recording if you missed it, and feel free to share your thoughts—we’d love to hear your feedback! 💡

 

 

  • Will the self-check in (Magic) Link be accessible via APIs in the future?
    • Today it is not possible to share guest portal links outside of Mews generated emails or SMS. This is for security & data privacy reasons: the guest portal holds the guest‘s personal information as well as details about all of the booking they’ve had across the portfolio of Mews properties and not only within a specific chain.
      The good news is that this is something we are addressing as part of the work we have done on the New Guest Portal (launching next week). The New Guest Portal is “chain-centric” which means guests will only see their stays within the same chain.
      For now, we are still working on the migration from the “current” to the “new” guest portal and improving the Online Check-in flow further. But once this is done, we want to explore how we could make the access links accessible i.e. via the API. We don’t have a timeline for this yet as the work on the new guest portal is not finished, but it’s on the list of things we want to pick-up.
  • We see that not all integration partners can keep up with the pace of Mews developing. Does somebody have advice on keeping integration partners sharp and focused on gathering their own info on updates etc?
    • Mews does have initiatives led by our Partners teams to encourage best practices and enhance awareness of new features and possibilities within our APIs.
      Mews Tech Stacks is an example of Mews recognizing Integration Partners who provide leading Solutions per region and industry segments.
      Our Technical Partners teams are in constant consideration of how to communicate the capabilities and changes to our APIs. A great example are the Use Cases, detailing how to address core functions.
      We actively encourage all Integration Partners to monitor Mews APIs for any changes and reaching out to us to see about opportunities to evolve their Integration and mutual benefit to Mews Customers.
  • Is there plans to make it easier to get access to the APIs? At least for read-only access. Certification process is very tedious as of now. Data-driven hotel staff would greatly benefit from getting easy access.
    • In the long run, we intend to enable integration partners to self-manage more aspects of their development process, and reduce reliance on manual intervention. We'd love to hear more about your workflow to identify the use cases that would make the most impact. If you or anyone else is open to talking about enabling more autonomy for our integration partners, please drop a comment and I'll reach out with a calendar link. For the moment, if you're building a custom integration for a specific customer, I would recommend requesting permission for all of the endpoints/data points you think you'll need for the foreseeable future.
  • We started with Mews early this summer and plan to do some integrations on our own. We have already explored the Mews API, and one thing that really stands out to me so far is that customer searches (/customers/getAll) are quite complicated due to strict technical limitations and a limited set of supported parameters. In many scenarios, I think it’s necessary to build a separate customer search index to effectively work with that data, which has several drawbacks, in my opinion. I was just wondering what the reason is for these stringent limitations, as I think this is a pretty common API operation and could be made significantly more versatile in its usage.
    • Indeed, the customers/getAll endpoint currently does not support fuzzy search. This is because the endpoint uses the same index for UI searches. For this to change and support fuzzy search, the domain team looking after profiles would have to update the index to support your search scenarios. We would be interested in learning more about your use case.

 

Be the first to reply!

Reply