Skip to main content

Why Aren't Guest Messages Reaching AXP from My Web Messenger?

This article is for properties using a custom Web Messenger integration (embedded in your own website or app) whose guest messages aren't arriving in AXP. Covers the most common cause — a mismatched short_property_code — and how to fix it.

Summary: If your property uses its own website or app to host the Web Messenger chat (rather than the standard AXP-hosted widget), guest messages can fail to reach AXP if the property code sent by your chat integration doesn't match the property code configured in AXP. This article explains how to check and correct this.

Permissions Required:

Location Admin or Brand Admin role in AXP to check the Short Property Code setting, plus access to the code or CMS where your Web Messenger integration is embedded (usually your web development or IT team) to update it.

📔 Note: This issue mainly affects properties with a custom Web Messenger integration (their own website or app), rather than the standard AXP-hosted chat widget.

Steps to follow

  1. Confirm the symptom — guests can send messages through your website's or app's chat widget, but these messages never appear in AXP, and as a result staff are unable to reply.

  2. Locate your Web Messenger integration code — this is the script your website or app uses to load the chat widget.

    It's usually placed in your site's template or CMS, or in your app's source code if you built a custom in-app chat.

    This will require your own property's web development or IT team to check and confirm, as this code sits outside of AXP.

  3. Find the short_property_code value — inside the integration code, look for a metadata section similar to the example below:

    delegate: {
    beforeSend(message, data) {
    message.metadata = {
    property_name: "Example Hotel",
    short_property_code: "EXAMPLE01",
    webpage_url: window.location.href,
    };
    return message;
    },
    },

  4. Check the code against AXP — a Location Admin or Brand Admin can find the correct short_property_code in AXP by going to Settings > Locations, opening the relevant location, going to the Details tab, and checking the Short Property Code field.

  5. Compare it with the value currently set in your integration code from step 3.

  6. Update the value if it doesn't match — edit the short_property_code in your integration code so it exactly matches the code confirmed in step 4, then save and deploy the change.

  7. Send a test message — use the chat widget to send a test message and confirm it appears in AXP and that staff can reply.


Common Questions

Q: Why did messages stop reaching AXP when nothing changed on the AXP side?

A: The short_property_code is sent by your Web Messenger integration, not configured within AXP. If this value is changed, removed, or set incorrectly in your website or app code — for example during a website update or app release — messages will stop being routed to the correct property in AXP.

Q: Where do I find the correct short property code for my property?

A: A Location Admin or Brand Admin can find this in AXP under Settings > Locations > select the location > Details tab > Short Property Code.

Q: I don't have a CMS for this integration — where do I make the change?

A: If your Web Messenger is embedded directly in your own app or website (rather than managed through a CMS), the fix needs to be made by whoever maintains that code — typically your in-house development team or your app's developer.

Q: Can Alliants Support update this for me?

A: No. Since the short_property_code is sent from your website or app rather than stored in AXP, this can only be corrected in your own integration code. You can look up the correct code yourself in AXP (see above).

Q: Will previously sent messages be recovered once the code is fixed?

A: No. Messages sent while the code mismatch was in place were not delivered to AXP and cannot be recovered. Once the code is corrected, new messages will route correctly.

💡 Tip: Double-check the short_property_code any time your website or app is updated or redeployed — accidental resets of this value are a common cause of this issue.

Did this answer your question?