Workspace API Endpoints

Workspaces was introduced in the product in November of 2022. Originally, when asked about API endpoints, there were no expected API endpoints. Opened a forum topic here in Feb:

Workspaces Support - Product - Freshworks Developer Community

Being a partner, we leverage the API’s every day. Ticket and KB migrations, CMDB population, importing and setup of Agents and many other facets of Onboarding and maintenance of Freshservice. We are trying to create tools for our teams, which move a lot of data in and out of Freshservice and have even provided a Powershell library for the entire Freshworks community to make the Freshservice API command-line accessible:

PowerShell Gallery | FreshservicePS 0.1.3

Documentation

As new features rollout, providing API capabilities and documentation seem to be a low priority or never occur. Many of the API endpoints are highly dependent on the id of an object to be able to make associations. There have been some updates for Workspaces showing up in the documentation (api.freshservice.com), such as the move ticket requested in the post above. This requires the workspace_id, however, no published GET method for Workspace. Taking a guess, there is a Workspaces endpoint:

PS C:\Build\FreshservicePS> Get-FSWorkspace
                                                                                                                        
created_at    : 7/25/2023 1:25:30 PM
description   : 
id            : 21000015068
logo          : 
name          : My Team
preferences   : @{personalized_email_replies=False; disable_agent_forward=False; email_spam_enabled=True; reply_to_based_tickets=True; remove_quoted_text=False}
primary       : True
restricted    : False
state         : 1
template_name : it
updated_at    : 7/25/2023 1:25:30 PM

Not in the documentation and more importantly, it does not have the workspace_id (e.g. display_id) required to associate for any public API endpoint reference. This requires someone to go into the interface to get information. Workspaces isn’t alone. For instance, On Call Schedule, been in the product for a year (It’s time! Sign up for On-Call Management Beta! | Freshworks Community), no API endpoint. The ocs_schedule_id is in the schema for Agent Groups, no endpoint published to GET the On Call Schedule.

There are many other ancillary impacted Workspace items, such as Agents. Recently, we had to determine how to assign business licenses and workspaces to many Agents. Nothing in the documentation, but first oddity is the Agent object schema changes when Business Licenses are added. Try to set workspace_info, API says no. Try to set workspace_ids, it works. Try to set license_type, it works. More often than not, we are trying to set endpoint properties or see if endpoints exist as there is no documentation. While this is not ideal, through trial and error we were able to perform these actions. However, if we want to update our public library, that is another case entirely as this is unpublished public functionality.

There was another conversation regarding search and default workspace behavior:

Different API Behavior in Multi-Workspace (Freshservice) - Product - Freshworks Developer Community

Found that using a Workspace Id of 0 will search all workspaces a user has access to, not in the documentation. There are many examples of missing important documentation.

What is the process for managing and updating the documentation?

Bug Remediation and Feature enhancements

The ability to move tickets between Workspaces showed up in the documentation approximately a month ago. Testing and adding this functionality, almost immediately found a bug, which was reported promptly to support:

[#14272933] Move Workspace Ticket API bug : Freshservice

No reply or status, we asked someone to provide status and it was routed to Marketing. Marketing?!? We have reported many other bugs, documentation issues, missing endpoints and not only are they rarely corrected, but there is also no communication regardless of how it is reported.

How do we drive product enhancement and innovation with no communication?

Change Tracking

Trying to track what changes have occurred in the API have been challenging as well. For months, we have been just doing a find on the documentation to search for workspace updates. Most of the API news is deprecation of V1 in Release notes in community.freshworks.com. The changelog is not being maintained:

Service Desk API for Developers | Freshservice

How are developers supposed to find changes in the API docs?

General Information\Account Endpoints

There are many dependencies on Freshservice version (e.g. is Workspace installed) or other components like license availability, plan, etc., but there are no published methods to GET account information. Is there a plan to provide a public account details endpoint? Something like…

{
  "instance_version": "2023.R07.06",
  "account_primary_last_name": "Smith",
  "data_center": "US",
  "asset_licenses": 100,
  "account_id": 54321,
  "account_plan": "Enterprise",
  "it_licenses": 50,
  "business_licenses": 100,
  "account_primary_email": "joe.smith@acme.com",
  "account_primary_first_name": "Joe",
  "account_name": "acmehelpdesk"
}

Having a general endpoint that is accessible by all API keys would allow methods to programmatically validate that a connection can be successfully made to the API without permission errors.

2 Likes

Hey Rob (@rasimm), it is refreshing to see such a detailed explanation of the many pain points so many of us are seeing. I can attest that traversing the documentation is taxing and often left with more questions than answers.

I appreciate you being so thorough in your examination of missing information. I was starting to think I was the only one really struggling. With the push to move all Freshservice Enterprise instances to Freshservice for Business Teams I feel API documentation would be of high priority.

I believe “Organizational Change” has caused a gap in communication. It is my hope that there is a remedy on that front here soon. But at least we can continue to support each other with our findings and lessons learned. So thanks again, for setting a good example on that front! :muscle:

@Tanmay_Kapoor, @Raviraj, @kaustavdm, @zach_jones_noel. How can we, the community, help facilitate your support efforts? How can we bridge some of these communication gaps that Rob is mentioning in his post? We would greatly appreciate any help you all could offer.

Thanks and take care! :slight_smile:

1 Like

Thank you, @rasimm , for providing such a comprehensive and insightful explanation of the challenges faced by partners and developers. Your feedback is immensely valuable to us, and it has shed light on how we can enhance the accessibility and usability of our API documentation.

Rest assured, we will proactively incorporate these suggestions into our plans. In the interim, if there are specific sets of APIs you would like to gain a deeper understanding of, please feel free to let us know. We’ll be more than happy to liaise with our engineering team to gather the necessary details and provide you with the assistance you require.

1 Like

Hi @Srikanth_Reddy,

**side note - the Bold tag is not rendering in the forum

Appreciate the response and would welcome collaboration for API enhancement. Being a light developer myself, one can only imagine the immense pressure and updates being asked of the development teams, but more often lately questions answered are by guessing and getting 404s and API validation errors that a property isn’t settable or contain a value that is pertinent. We can ask if there is a Workspaces endpoint or try hitting it to see what payload is returned. No documentation on business licenses, do a GET to see the schema and start guessing on what is settable. The forums usually take several days to get responses, so strong documentation is imperative.

The Powershell module, essentially wrapper functions for the API, we’re attempting to provide and maintain has the goal of making the API more consumable by Freshservice Administrators or agents in general. It is highly likely that yourself or developers in general are using command-line interfaces for *nix, Windows, databases and even your own FDK. The goal is provide a way to manage Freshservice outside of the GUI interface. Want to get all tickets with stats, create a connection and it’s a simple command:

Get-FSTicket -include stats

The communities only resource to know what endpoints are available, what properties are settable, any validation rules, etc. is the documentation. Finding filters, url parameters and other solutions in a Forum should be answered with, look at the documentation here, not here is an undocumented solution (imho).

The immediate need from my team is insight on Workspaces. Customers should already have or be getting Workspaces in the next coming weeks. It has been a bit of a roller coaster trying to understand exactly what is changing in the product. For instance, Restricted Groups. Originally, restricted groups were going away in favor or Restricted Workspaces. Then Restricted groups came back for the primary workspace only to support backwards compatibility. If you did not have any restricted groups or removed all restricted groups, the feature is disabled per my personal understanding. In the background, we are trying to write code, deprecate or update endpoints\commands or provide examples, but the documentation is stale.

Workspace Endpoint

As mentioned above, there is not a published endpoint for Workspaces. It appears there is a public GET available (e.g. https://{{fs_base_url}}.freshservice.com/api/v2/workspaces), however, it does not have the display id (i.e. workspace_id) required by the other API methods\payloads.

Tickets

Default Behavior

If a GET is done on tickets, the expectation is that the user doesn't know or care about the inner workings of Freshservice Workspace ticket buckets, permissions, etc. and returns tickets that the user with that API key has access to. By defaulting to only returning what is in the primary (typically IT) workspace, makes it a bit of a challenge. If I am on a non-Workspace tenant and I change my default GET tickets to append ?workspace=0, what will happen? Will I get an error that tells me that workspaces do not exist on the tenant? A 404? The url query will be ignored? The current push is that all tenants will have Workspaces, but the goal is even if someone is an agent in a non-primary workspace like HR to execute a GET and see their tickets without the need to specify workspace or other information. The goal is we can provide a command, Get-FSTicket and it returns tickets, so how do we accomplish this with the default behaviors with workspace and non-workspace tenants. This goes back to the question about having general account information to have context to provide logic around when a url would have workspace=0 appended. The goal is to make it simple and intuitive to a user and no expectation to know about the product configuration per se. We are attempting to support compatibility across any tenant, so any guidance is welcome.

Ticket Move Bug

We have code ready to publish to support the Move Workspace functionality, but we were waiting on this bug to be remediated. There is no ticket{} wrapper in the result, so the default parsing doesn’t work:

[#14272933] Move Workspace Ticket API bug : Freshservice

Change, Problem and Release were also tested and they have the proper respective wrappers per the documentation.

@rasimm
Thank you for providing your feedback on our APIs. We’re already working on ensuring workspace compatibility for all our APIs, and you should see the changes being rolled out incrementally over the next few months. Thank you for your patience.

As for your question about Restricted Groups - while we originally intended to deprecate Restricted Groups in favour of Restricted Workspaces, we received feedback from many of our customers that they needed both these features to co-exist. We’re therefore working on enabling restricted groups across all workspaces on workspace-enabled accounts - you should see these changes being rolled out over the next few months as well.

1 Like