Live Agent Handoff - Webhook Token for Glia - LIVE_AGENT_UNABLE_TO_START_CONVERSATION

Hi all, I think I have the correct webhook token now, but I am getting the following response:

I attempted again to start a live agent chat for you with the description you provided, but the request failed due to an internal system error with the target URL (https:///visitors?")`), so the conversation with a live agent could not be opened.

How/where change I alter the target URL?

Hi,

It looks like you have the wrong connector selected in Handoff → Live Agent Handoff. Kindly change it to the one that you recently created and try again.

Hi, I reverted to that one and got the same result, so then I tried changing the api key id for that connector (as I’m not actually sure which api key ID to use for the connector) as well and I’m still not able to successfully accomplish the live agent handoff

I think we are failing to generate the token. It might be that the credentials in the connector are not valid. Can you run this cURL request with the ID and secret that you have in the connector ?

 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>"}'

I honestly am not sure which is the correct api key id and which is the correct api key secret. So I’d like to generate new ones entirely instead of trying to find out what the previous ones were. What would be the best way to do that?

Nevermind, I just generated a new client ID and secret and inputted it into the connector, will try to test out now

Ok, here are the steps i took:

-generated a new client ID and secret and inputted it into the GliaSandbox connector

-GliaSandbox connector is the Select Connector for the live agent handoff

-Webhook is set to GliaSandbox, UID from webhook is retrieved and is inputted into live agent handoff

Perhaps the Queue ID or even the Site ID is incorrect? Not sure what else the issue might be

You can find the site ID in the Settings section in your instance and you can find the queue ID under the queue section.

As for the secret make sure that it is within the character limit which is 40 characters. More information on this can be found here.

As for access guide, you can find that document here.

Hi, i generated a new api key and secret from Glia, I inputted it into the connector, I’m using the webhook token associated with GliaSandbox connector, and I verified that the correct Site ID is being used. Not sure what else there is to try.

​@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.

Hi, thank you for this information and for your time and assistance on this matter.

I used the service credential API Key and secret to successfully create a bearer token here:

https://docs.glia.com/glia-dev/reference/post_operator-authentication-tokens

I then used that bearer token for the POST /visitors API, with a successful response.

I added the additional visitor and queue policies to the service credential - I attached to this post all the policies that are included with the service credential.

This base URL should be the correct one but I will verify with Glia.

Any other thoughts/ideas? I tried it again and still nothing. Maybe I need to try something else for the webhook token in the Live Agent Handoff section?

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

Hey ​@jtheohar314,

I connected with the engineer assigned to your ticket and we did a check on the logs. The root cause is clear — the failure is happening at the OAuth token exchange step, before any Glia API calls are even made.

Root Cause: Our Glia connector currently authenticates by exchanging credentials at Glia's POST /sites/tokens endpoint. This endpoint is designed for Glia's legacy Site API Keys. When you provide the newer Service Credentials, the request is rejected with a 422 Unprocessable Entity because the secret format/prefix doesn't match what /sites/tokens expects.

Based on Glia's developer tooling (https://github.com/salemove/glia-functions-tools), Service Credentials should authenticate against a different endpoint — POST /operator_authentication/tokens — rather than /sites/tokens. Our connector doesn't currently support this endpoint, and it's not something configurable on your end — it's set platform-side.

What's happening next:

We've notified our engineering team to look into this and make sure that’s the new endpoint

I'd also recommend confirming with Glia that /operator_authentication/tokens is the correct endpoint for Service Credentials, since their public docs on this are limited and it would help us fix this ASAP.

I was able to generate a token properly when I used the /operator_authentication/tokens API with the api key and secret that came from the new Service Credentials but I just reached out to Glia support for them to verify that too.

​@Kevin Mok 

Yes, we can confirm that /operator_authentication/tokens is the correct endpoint for fetching the Bearer Token for Service Credentials.

The reason Service Credentials use the operator endpoint is because Glia authenticates the integration as a dedicated service user.

Thanks for the confirmation! We’ll get this handled and keep you updated