Workspace-Level Custom Field API Access Issue

I would like to search a freshservice workspace for any tickets with a foreign key (9128120) in a custom field (f_key).

Query:

https://my_org.freshservice.com/api/v2/tickets/filter?query="f_key: 9128120 and workspace_id: 4" 

When I attempt to search for this value in the f_key custom field of workspace 4, I consistently get “unexpected / invalid field in request” error.

I have tried a variety of quotes, url encoding, prepending the custom field with cf. and cf_ as shown in some suggestions, and have tried workspace_id: 0 as well.

Is anyone else able to get workspace-level custom fields via filter / query?

Json snippet from the freshservice ticket in workspace 4 that has the f_key custom field and value:

        "custom_fields": {
            "f_key": 9128120,
            "major_incident_type": null,
            "business_impact": null,
            "impacted_locations": null,
            "no_of_customers_impacted": null
        },

Response:

{
    "description": "Validation failed",
    "errors": [
        {
            "field": "f_key",
            "message": "Unexpected/invalid field in request",
            "code": "invalid_value"
        }
    ]
}

DETAILS:

I’m trying to use workflow automator to process inbound tickets via the email gateway from another ticketing system with its own ticket numbers in the subject of the incoming messages.

The other ticketing system will send emails to the freshservice workspace when a ticket is opened, updated, and closed.

Currently, these all come in as separate, unconnected, new tickets in the freshservice workspace. Instead I would like all messages with the same foreign key to be consolidated into a set or group.

  • OPEN: If a message comes from the other ticketing system with a ticket number that isn’t already in the freshservice workspace, I would like to create a new ticket.

  • UPDATE: if a message comes in from the other ticketing system with a foreign key that already has a freshservice ticket created, but does not have the word “Closed” in the subject, make the current ticket a child ticket of the existing freshservice ticket with the matching foreign key.

  • CLOSE: if a message comes in from the other ticketing system with a foreign key that already has a matching freshservice ticket, and the subject contains the word “Closed”, set the status of the ticket(s) with the same foreign key to closed.

I have captured the foreign ticket key from the subject using a substring function.

Hi @Cian_Phillips,

Greetings, and welcome to the community! :tada:

You’re absolutely right to dig into this — and you’re not alone. Freshservice’s custom fields are scoped per workspace, which means a custom field (like f_key) created in Workspace 4 won’t be recognized in another workspace, and vice versa.

When using the /tickets/filter API, the query parser will return an “unexpected/invalid field” error if:

  1. The field does not exist in the specified workspace.
  2. The field name is not properly referenced (e.g., custom fields often use the custom_fields.<field_name> format in filtering).

Unfortunately, as of now, the filter endpoint doesn’t allow querying directly on custom_fields in the way you’re trying. The API doesn’t yet support full-text or indexed searching on custom field values through the filter/query param.

Suggested Workaround:

To implement your “OPEN / UPDATE / CLOSE” logic, you may need to:

  • List all tickets in the workspace using /tickets API or use Ticket Create product event in SDK app.
  • Filter them in your app or middleware by checking custom_fields.f_key manually for a match.
  • Proceed to create, update, or close tickets accordingly.

This isn’t as elegant as direct filtering, but it’s the most reliable approach right now.

Let us know if you’d like help designing the logic or if Freshworks updates support this feature natively in the future.

Hope this helps!

Thanks for the quick response Bene!

I have written some Python integrations that create tickets in FreshService and I had a similar challenge. I labeled all the auto-generated tickets with a tag (e.g., from_external_system) then queried on all active statuses and the tag and looped through those which seemed to make this a more manageable list but I was hoping for something a little less kludgey since I intend to now reuse this code for several additional systems.

It seems that allowing parsing of the subject line and providing some minimal wildcard functionality would go a long ways towards being able to more easily support integration with other systems.

Thanks again,

Cian