Different API Behavior in Multi-Workspace (Freshservice)

Hello Team,

We have observed distinct behaviors when accessing the Freshservice API in multi-workspace environments. Here are the specific occurrences:

  1. The List Ticket API does not seem to retrieve any tickets of the “Request” type.
  2. However, the View Ticket API successfully returns tickets of the “Request” type.
  3. Additionally, the Filter Ticket API is not returning any tickets of the “Request” type.

We are curious about the rationale behind these different behaviors when accessing tickets based on their type, especially for the “Request” type. Is there any specific configuration required to ensure that all ticket types, including “Request,” can be pulled through the API?

Your insights on this matter would be greatly appreciated. If you need any further information from our end, please let us know. Thank you for your assistance!

@ajithr I suspect that the tickets of type “Request” aren’t in your primary workspace. When you invoke GET on /api/v2/tickets, only the tickets from the primary workspace are returned in the response. If you’re trying to get tickets from another workspace, you can invoke GET on /api/v2/tickets?workspace_id=[id].


The documentation has workspace_id as a body payload, not url query. Not sure if both work?

Trying to understand some of the behaviors on this as well. If I’m a workspace admin on 3 workspaces, should the default behavior return all tickets I have access to? If I want to return tickets for workspaces 1,3 and 4, the workspace id is a single value, not multi value (e.g. workspace_id=1,3,4). If I want all open tickets for me, in all workspaces, I would have to loop through all Workspaces and essentially ignore queries with errors. A GET on Tickets should return tickets across all workspaces and then have filtering to narrow down if I want tickets from specific place, imho. What if someone is not part of the primary workspace, like a HR workspace and does a GET? No tickets are returned. It seems counter intuitive to tell them they have to provide a specific workspace.

Although it’s not published, performing a GET on https://domain.freshservice.com/api/v2/workspaces lists the id of workspaces, but not the display_id of workspaces. Even in the scenario above, there isn’t a way to know what workspaces are available or the display_name of the Workspace without the object having a display_id.

1 Like

The solution that worked for me was to include “workspace_id: 0” in the query. Using the value 0 for “workspace_id” allows the query to return tickets from all workspaces.

This topic was automatically closed 6 days after the last reply. New replies are no longer allowed.