Skip to main content
Visit Freshworks.com Visit Freshworks

I would like to get the public URL thru the api some how


As example 

http://xxxxx.freshdesk.com/public/tickets/111b7a19024558a3730bf35ad8aabAAA


Is there any way to get this number "111b7a19024558a3730bf35ad8aabAAA" via api?


Thank you 


Jason



Hello Jason,


This is not possible currently. Could you give us a few more details about the use case for this requirement?


Thanks,

Rohit



Hi Rohit,


I'm very interested in this feature too. Here's my use case:


We have a web application for managing customer orders.

When a customer views an order in our web app, I would like to display a list of any support tickets relating to that order, and have them clickable as public links.


We have SSO set up with our web app, but for a number of reasons public links would make things much easier. Reason #1 is that an order in our app may be associated with many customers, so a public link means that anyone viewing the order in our app can access the ticket, not just the person who created the ticket.


Any chance this feature could be added? 




Hi Rohit,


I'd really like this feature. My use case is this:


We have a web app where customers can view their orders. I'd like to display a list of tickets related to that order, and have clickable public links. 


SSO doesn't really work for this use case because more than one customer can view a single order in our app. So Customer#1 could create a ticket for the order and Customer#2 needs to be able to view the ticket too.


Does that make sense? Any chance this feature can be implemented?



Thanks for the reply. I understand the use case clearly now and it definitely makes a lot of sense. 


I will take it down as a feature request for now and update this post when we take it up. We have a lot on our plate currently, so I cannot give an ETA right now, but we will keep it in mind.



+1


Using a Desktop client and would be useful to glean the tickets public URL.



+1


I'm also very interested on this feature. 



Hi all,


I had an answer from one of their support agents via email. Not sure if they have mentioned this publicly elsewhere. I haven't tried this yet, but it looks like this should be possible. Here's the email:


-------------------------




And yes, we can use the "Dispatch'r" and set up a rule such that the "public ticket URL" is populated in one of the custom ticket fields. 






Once this is done, you can use APIs to pull this data. 






I believe this helps. 






Let me know if you need anything more from my side. 






Waiting to hear from you. 






Best Regards,



Vignesh.C












Thanks Jake,


I've tried. Doesn't work the way I'm doing it.

I updated the custom field with {{ticket.public_url}}, ticket.public_url, public_url. None of them worked.


Thinking a webook maybe helps.




My custom web app is integrated with Freshdesk Support. Once the user logs in to my web portal, a support icon will be available on the home page of my web app, on click of which, the user will be directed to the Freshdesk Support. However, I do not want to show him the Tickets tab, or to be able to create a new ticket from here. I want a separate icon for ticket creation on my web portal (after login), on click of which, the user can open a new ticket. This is because among the logged in user, I only want licensed users to be able to create and view tickets, which I am handling in my web app. Please let me know if I need to use any API or freshplug widgets for this and if so which API??



The issue with using Dispatch'r is that it stops processing rules after the first match. That seems to mean that using this method would render Dispatch'r unusable for any other purpose.



Just wondering if anyone has made progress on a workaround to get public URL from the API or it will be available from the API.
I am also trying to develop a custom web app that will let users view the tickets they have submitted without logging in by using their email.




+1





Freshdesk, is this done?





Waiting Skeleton - Waiting for freshdesk to add this simple property 3 years later....





I have a not-great solution that's working okay for us. Still, I can't believe this isn't in the public API yet.






Our solution includes a custom text field to store the public ticket URL in. And it also includes a custom checkbox/toggle field named "Public Ticket URL" set to OFF by default. When our Organizer rule runs, we set (check ON) this checkbox after putting the public ticket URL in the string field. And the Observer rule ignores tickets that have this toggled ON, which is how we avoid this pointlessly updating the string on tickets that we've already populated it in.






We were told we'd have to use the V1 API for some reason, but I forget why now.






See attached pic. If you want to get this working for yourself, I suggest you open a ticket with Freshdesk and point them here if you want to prime the pump. I didn't put the pic inline because it'd just glut this thread.



w10--2018-01-22_2c150258--adminobserverrule_30637.png


Mr. Smith that's a great solution! Except I can't seem to get it to work lol! I use the callback URL, my API key, and json body in PostMan to test and it works great. I build the observer rule to look the same as yours and it just doesn't want to do it. I don't get it this should work as you described. The only difference between our observer rules is I'm not using a custom boolean field for my condition I'm doing "Public URL > Does not Contain > https://"






Any thoughts on what I might be missing? I attached a screen similar to yours in case anything stands out that I'm just missing.



gdgfxfghibifgfp_5b1_5d_30647.png


No idea, Joshua. I'd open a ticket with Freshdesk. They're very responsive and helpful.





In my recent experience I tend to disagree, but this was supposed to be a workaround to another issue so I'll tell them I need a different workaround. Thanks for the idea anyways it was worth a shot.





Thanks for the suggestion,Mr.Smith 🙂 The reason why we (myself and Vishwa) had this setup through API V1 was to avoid the mandatory field error that would popup when you merge a ticket.






@Joshua: One of our experts would get in touch with you soon to help you setup this rule.






Cheers!





Thanks, Aravind. I had a note about why you did that, but I since deleted that rule and had to recreated it (d'oh!), losing my note.





Citing the email from this morning that the v1 API will be shut of 7/1, what is the next course of action for this as the webhooks currently setup will cease to work?



Terms of Use