Live Agent Handoff - Webhook Token for Glia - LIVE_AGENT_UNABLE_TO_START_CONVERSATION

​@varockiasamy Hi, wondering if you have any thoughts on how best to solve this? Thank you

Hi,

I recommend reviewing the secret and making sure it is within the character limit which is 40 characters. Also, test it against this endpoint and see if you are getting a 200 response code with the token in the response.

 curl -X POST https://api.glia.com/sites/tokens \
    -H "Content-Type: application/json" \
    -H "Accept: application/vnd.salemove.v1+json" \
    -d '{"api_key_id":"<your_id>","api_key_secret":"<your_secret>"}'

You can also create a case with our support team if you are still seeing issues and they can help you troubleshoot it further.

Hi ​@varockiasamy , this link doesn’t seem to be working anymore: https://help.moveworks.com/reference/get-api-keys

Hi ​@jtheohar314 , We have migrated from help.moveworks.com to docs.moveworks.com. You can find instructions on generating an API key here.

​@varockiasamy Hi there, it seems that generating an api key and secret with that method results in a secret that is far longer than 40 characters (approximately 104 characters). And the key and secret don’t work when plugged into the Connector.

Additionally, I’ve come across documentation such as this https://docs.moveworks.com/service-management/access-requirements/live-agent-chat/glia-access-requirements#3-share-additional-required-details-for-configuration stating that Moveworks still requires a legacy Site API key with required scopes Create Visitor, Fetch Visitor, Fetch Engagement, Update Engagement, Fetch Engagement Requests, Invoke Glia Functions, and Fetch Glia Functions. 
 

Glia no longer allows creation of new Site API Keys after 1/1/2026. We did create a new User api key/secret as requested by Glia Support which does work when attempting a Curl to request a token with https://api.salemove.com/operator_authentication/tokens. But the key ID and secret do not work when plugged into our Moveworks connector, perhaps due to the missing scopes or due to the fact that Moveworks still only accepts site api keys.

Are you able to provide confirmation that the Moveworks connector does accept User API Keys?

Thank you for your help with this matter.

Hi all, issue is still not resolved. ​@varockiasamy  ​@Kevin Mok 

We're working on configuring the live agent handoff in our sandbox environment in order for our user path to go from Moveworks to Glia.

According to the various documentation and discussions in the Moveworks community, this connection is made by plugging in Glia credentials into a Moveworks connector, and referencing that Moveworks connector in the Select Connector section of the Moveworks live agent handoff section.

The following doc explained how to generate Glia credentials, add scopes/policies, and input the credentials into a connector (which our live handoff configuration references), and I will explain shortly the issue that we're facing for this:
https://docs.moveworks.com/service-management/access-requirements/live-agent-chat/glia-access-requirements

In order to generate the webhook token, I went to HTTP Connectors -> Credentials and generated a new API key, and inputted that into the Webhook Token (The webhook token for Glia Integration) on the Live Agent Handoff page:
https://docs.moveworks.com/api-reference/api-credentials

One complication we've run into is that the credential (Glia Site API Key) referenced in the Moveworks documentation & community has been deprecated on the Glia side. Glia now recommends using a glia Service Credential instead.

To adapt to this change, I generated a new Glia Service Credential, captured the API key id/secret, and added the required Moveworks scopes/policies based on Glia’s updated list of policies (previously known as scopes). I then configured these credentials in the Moveworks Glia Connector and referenced that connector in the Live Agent Handoff configuration.

However, the bot handoff is still not working in sandbox.

Can someone please advise on the following:
1. Whether Moveworks Glia connector is fully compatible with glia Service Credentials, or if it still requires the legacy Site API Key.
2. Whether there are any additional policies or permissions (scopes) required on the Glia side for the handoff flow beyond what is included on this page: https://docs.moveworks.com/service-management/access-requirements/live-agent-chat/glia-access-requirements
3. If there is a location in Moveworks where I can view logs or API activity when the handoff attempt occurs
4. If you see anything incorrect in this process or steps of getting this sandbox environment configured properly for live agent handoff from Moveworks to Glia.

Thank you in advance!

Hey ​@jtheohar314,

Thanks for the detailed writeup — this is really helpful context.

On compatibility with Glia Service Credentials:

The Moveworks Glia connector authenticates using OAuth 2.0 with the client_credentials grant type. It takes a client ID and client secret, exchanges them for a bearer token, and uses that token to call Glia's REST API. It is not hardcoded to "Site API Keys" specifically — so Service Credentials should work as a drop-in replacement, as long as the OAuth token exchange and subsequent API behavior remain the same on Glia's side.

On the handoff flow and what permissions are actually required:

During a live agent handoff, Moveworks makes the following API calls to Glia in this order:

1. POST /visitors — Creates a visitor (this is the only call that uses the connector's OAuth token directly)
2. PATCH /sites/{site_id}/visitors/{visitor_id} — Updates the visitor with user details
3. POST /queue_tickets — Submits the visitor to the configured queue for agent routing
4. PUT /engagements/{engagement_id}/chat_messages/{message_id} — Sends messages during the engagement
5. PATCH /engagements/{engagement_id} — Ends the engagement

This is likely where the issue is — our documentation page lists 7 scopes, but the handoff flow also requires permissions for operations that aren't explicitly called out:

- Update Visitor (for the PATCH /sites/{site_id}/visitors/{visitor_id} call)
- Create Queue Ticket (for the POST /queue_tickets call)

With the legacy Site API Keys, these may have been implicitly granted. With the new Service Credentials and their explicit "policies" model, you likely need to ensure these are also included. I'd recommend adding all available visitor and queue-related policies on your Service Credential, not just the 7 listed in our docs.

Troubleshooting steps I'd suggest:

1. Verify the OAuth token exchange works independently — Use curl or Postman to confirm you can obtain a bearer token from Glia's token endpoint using your Service Credential ID and secret with a client_credentials grant. If this fails, the issue is at the token level.

2. Test POST /visitors directly — Once you have a token, try calling POST /visitors against your Glia instance with the bearer token in the Authorization header and Accept: application/vnd.salemove.v1+json. This is the first API call in the handoff flow and the most likely failure point.

3. Double-check all policies on your Service Credential — Make sure you have policies covering: create visitor, update visitor, fetch visitor, create queue ticket, fetch engagement, update engagement, fetch engagement requests, invoke Glia functions, and fetch Glia functions.

4. Confirm the base URL hasn't changed — Some vendors use different API base URLs for different credential types. Verify that the base URL configured in your Moveworks connector matches what Glia expects for Service Credentials.

I am also flagging internally that our docs page needs to be updated to reflect the deprecation of Site API Keys and include the full set of required policies. Thanks for surfacing this.

I see ​@jtheohar314 - Are you currently working with a support engineer that could take a look at logs to see the exact error in the backend? That would give us an idea for the exact error/
I wouldn’t be able to check for you, it needs to be someone from that team.

I opened a ticket with ​@Pradhan Shreya Swaraj a few days ago but I haven’t heard any updates yet - I did request for him to look through the logs during the handoff