There appears to be some differences in the way the Freshchat API behaves with these new url access points (.api.freshchat) to the previous ones (.subdomain.freshchat). I am having trouble using the conversations end point in postman to get conversation details or post messages to it but I am using exactly the same methods as I use with the old url.
returns the following even though I captured the conversation ID via the console from an installed custom app.
"message": "Conversation Not Found"
Also when trying to post a message to a chat with a stringified payload in the body I get the following error with the new urls. I tried to get this to work in postman and it suggested the end point doesn’t like the payload.
Any chance of an online session to look at this as this all worked fine against the old url access point.
Thanks for this. The conversation ID I used was captured by logging the ID from onConversationUpdate event in a serverless app. It was provided directly in the payload provided with this event by Freshchat.
Thanks for the updates, @Rob. Glad to know it works now, though I am pretty sure we did nothing on our end to sort it. We were trying to find out how to find the API base URL information for bundled Freshchat accounts.
Did you finally use the *.myfreshworks.com domain?
No. I used api.eu.freschat.com. I suspected something was being worked on yesterday as the developer portal went down for a while, but I think that may have been the rollout of the ‘In testing’ feature. I should add that this base also works on non bundled accounts as well.
I now run a small bit of discovery code to identify the correct base url. If its not the right one of the 4 AWS locations of your instance, you get a 400 status and the following message
This process is a bit nasty so it would be nice to have the appropriate base url in the iparams of the event payload and in the client object. This would then remove the need to try and discover it on install.