Smoobu integration: Nuki invitation emails become unusable in Booking.com Messenger

Hello Nuki Developer Community,

Nuki Support asked me to raise this issue in the Developer Forum.

I use the official Smoobu integration for a holiday apartment with the following setup:

  • Smoobu as the channel manager
  • Booking com as the booking platform
  • Nuki Smart Lock for the apartment door
  • Nuki Opener for the building entrance
  • Nuki Web / Short-Term Rental integration

Current workflow

For a Booking .com reservation, the following process appears to take place:

  1. Booking creates an anonymised guest email alias ending in @guest.booking .com.

  2. Booking sends the booking data and alias address to Smoobu.

  3. Smoobu passes the relevant booking data and guest alias address to Nuki through the existing integration.

  4. Nuki generates individual invitation codes for:

    • the apartment door / Smart Lock
    • the building entrance / Opener
    • each individual guest
  5. Nuki sends the invitation email from contact@nuki.io directly to the Booking guest alias address.

  6. Booking processes the incoming HTML email and displays it in the Booking Messenger.

Actual problem

The Nuki email is delivered, and the correct booking data and invitation codes are generated.

However, Booking converts or sanitises the HTML email. As a result:

  • the HTML tables are broken into lines and text fragments;
  • the message becomes extremely difficult to read;
  • the “Open door via web link” link is removed or no longer clickable;
  • the “Redeem now” links are displayed only as plain text;
  • the guest cannot easily understand which invitation belongs to the building entrance and which belongs to the apartment door;
  • technically inexperienced guests often require manual assistance from the host.

This proves that the connection between Smoobu and Nuki is generally working. The issue occurs after Nuki has generated and sent the invitation email.

I have attached a redacted PDF showing the actual message as displayed in the Booking Messenger. All guest names and active invitation codes have been removed.

Proposed short-term solution

Nuki could select the email format based on the recipient domain:

Normal email address
→ existing formatted HTML invitation

Recipient address ending in @guest.booking.com
→ simple plain-text invitation

The plain-text version could contain only the essential information, for example:

Your digital access details

Guest 1

Building entrance:
Invitation code for the Nuki app: XXX-XXX-XXX

Apartment door:
Invitation code for the Nuki app: XXX-XXX-XXX

Links may still be included, but the email must remain understandable and usable even if the receiving platform removes HTML formatting and hyperlinks.

An alternative would be to send the message as multipart/alternative, containing:

  • the current HTML version;
  • a complete plain-text fallback version.

Another possible solution would be for Smoobu to pass booking-channel metadata through the API, allowing Nuki to select a Booking.com-compatible email template.

Questions

  1. Is the current Nuki invitation email sent as HTML only, or as multipart/alternative with a complete plain-text part?

  2. Can Nuki select a different invitation template depending on the recipient domain?

  3. Can Smoobu pass the booking source or channel information to Nuki through the existing integration?

  4. Is there an API option for retrieving the invitation data in a structured form, including:

    • guest number;
    • door or device;
    • invitation code;
    • invitation link;
    • validity period?
  5. Can the Short-Term Rental invitation template be configured through Nuki Web or an API?

  6. Could Nuki introduce a plain-text fallback specifically for addresses ending in @guest.booking .com?

  7. Which Nuki product or integration team is responsible for the Smoobu Short-Term Rental integration?

This issue has existed for several months and has already been reported to Nuki Support several times. Reconnecting the Smoobu integration or deleting and reconnecting the devices does not solve the problem, because the booking data and invitation codes are generated correctly.

The current workaround suggested by Support is to send the invitation only to the host, manually rewrite it, and then forward it to the guest. This is not a viable solution for an automated self-check-in process.

Thank you for any technical clarification or assistance.