Looking for a consistent way to query ticket fields

Product
1

I am trying to use the api to query ticket fields, but am running into the following issues:

  1. When I use the end point subdomain.freshdesk.com/api/v2/ticket_fields/ things work fine but when I try to get an individual field using subdomain.freshdesk.com/api/v2/ticket_fields/12345 I get a 404 error.

  2. I tried the newer endpoint, which is subdomain.freshdesk.com/api/v2/admin/ticket_fields/12345. This does give me a result but for multi-choice ticket fields there seems to be no consistent structure. I basically want a ‘label’, and a ‘value’ for each option.

Instead, I get this:
(a) For the Type field I get value and parent_choice_id
(b) For Source I get label and value
© For Status I get label_for_customers and value
(d) For Priority I get label and value
(e) For a custom dropdown field I get parent_choice_id and value

Please advice.

2 Likes
3

@ncrafts,

Can you share the payload structure for this? As an example that might help.

I intend to see if there’s another part that would cost another api call.

4

Should I share the response I get from the Freshdesk server, as JSON?

6

As simple as,

{
 "property":  value,
 "key": "value"
}

as a example should be sufficient, Nishant

7

When I query ticket_type field this is the value of ‘choices’:

[{
    "id": 1,
    "position": 1,
    "value": "Application Support",
    "parent_choice_id": 36000473373,
    "choices": []
}, {
    "id": 2,
    "position": 2,
    "value": "Incident",
    "parent_choice_id": 36000473373,
    "choices": []
}, {
    "id": 3,
    "position": 3,
    "value": "Problem",
    "parent_choice_id": 36000473373,
    "choices": []
}, {
    "id": 4,
    "position": 4,
    "value": "Feature Request",
    "parent_choice_id": 36000473373,
    "choices": []
}]

For sources it is this:

[{
    "label": "Email",
    "value": 1,
    "id": 1,
    "position": 1,
    "icon_id": 1,
    "default": true,
    "deleted": false
}, {
    "label": "Portal",
    "value": 2,
    "id": 2,
    "position": 2,
    "icon_id": 2,
    "default": true,
    "deleted": false
}, {
    "label": "Phone",
    "value": 3,
    "id": 3,
    "position": 3,
    "icon_id": 3,
    "default": true,
    "deleted": false
}, {
    "label": "Forum",
    "value": 4,
    "id": 4,
    "position": 4,
    "icon_id": 4,
    "default": true,
    "deleted": false
}, {
    "label": "Twitter",
    "value": 5,
    "id": 5,
    "position": 5,
    "icon_id": 5,
    "default": true,
    "deleted": false
}, {
    "label": "Facebook",
    "value": 6,
    "id": 6,
    "position": 6,
    "icon_id": 6,
    "default": true,
    "deleted": false
}, {
    "label": "Chat",
    "value": 7,
    "id": 7,
    "position": 7,
    "icon_id": 7,
    "default": true,
    "deleted": false
}, {
    "label": "Feedback Widget",
    "value": 9,
    "id": 9,
    "position": 8,
    "icon_id": 9,
    "default": true,
    "deleted": false
}, {
    "label": "Outbound Email",
    "value": 10,
    "id": 10,
    "position": 9,
    "icon_id": 10,
    "default": true,
    "deleted": false
}, {
    "label": "Ecommerce",
    "value": 11,
    "id": 11,
    "position": 10,
    "icon_id": 11,
    "default": true,
    "deleted": false
}, {
    "label": "Bot",
    "value": 12,
    "id": 12,
    "position": 11,
    "icon_id": 12,
    "default": true,
    "deleted": false
}, {
    "label": "Whatsapp",
    "value": 13,
    "id": 13,
    "position": 12,
    "icon_id": 13,
    "default": true,
    "deleted": false
}]

I get a different structure for most fields.

8

As far as I understood, You are trying to consume Ticket Fields APIs to GET a particular Ticket Field and yet the properties in the response from of a Source. Type,Status, Priority ticket field and custom ticket field are not same.

The way to consume label and value are different for different fields.

Am I correct? @ncrafts

Let me work with :freshdesk: team and keep you posted. Please correct me if my understanding can be corrected any way.

10

I am basically using the ticket API to generate a form. I understand they are different types of fields in nature, but they follow the same key: value format.

The issue here is that when querying the API this key is sometimes called ‘key’, sometimes ‘id’, and this label is sometimes called ‘label’ and sometimes ‘label for customer’. And this is simply the new API end point.

If I use the current documented endpoint subdomain.freshdesk.com/api/v2/ticket_fields/ I see a whole different structure. With this, sometimes the keys are numeric like 1, 2, 3 (which is great) but for some fields the keys are text and the values are numeric (1, 2, 3).

Here’s an example for the source field:

{
    "Email": 1,
    "Portal": 2,
    "Phone": 3,
    "Forum": 4,
    "Twitter": 5,
    "Facebook": 6,
    "Chat": 7,
    "MobiHelp": 8,
    "Feedback Widget": 9,
    "Outbound Email": 10,
    "Ecommerce": 11,
    "Bot": 12,
    "Whatsapp": 13
}

And here is the status field:

{
    "2": [
        "Open",
        "Being Processed"
    ],
    "3": [
        "Pending",
        "Awaiting your Reply"
    ],
    "4": [
        "Resolved",
        "This ticket has been Resolved"
    ],
    "5": [
        "Closed",
        "This ticket has been Closed"
    ]
}

See, if you follow a consistent key: value format for naming field options you can scale to a 100 types of fields and the developer wouldn’t have to write more code to accommodate that. The way things are right now, I’d be writing a different piece of code for each field, and for each API version.

11

Hi Nishant,

I learnt from :freshdesk: team that it is recognised to be inconsistent due to varied development efforts. But currently, trying to change them would cause breakage with applications consuming it as they are today. So we may have to go with the inconsistent responses as you see them.

However, teams are working together to follow an API Spec to be consistent across products. But it is not something which is near term that we could rely upon.

cc:@ncrafts

12

Ok, that’s good to know. Thank you for helping out so far Saif.

2 Likes