Create ticket via powershell fails due to invalid responder_id

Hi,

I’m currently in the process of writing a PowerShell script to create tickets, but for some reason it keeps complaining about an invalid responder_id:

{@{field=responder_id; message=Invalid responder_id; code=invalid_value}}

I’ve tried several responder_id’s, that I fetched using a GET command, but it keeps returning the same error. One time it give a different error: not part of group_id (or something like that), which made sense as the id used was indeed not member of the used group_id. But even after using a responder_id that is part of the group_id it keeps returning above error.

Here’s my code:

$APIKey = "**MyApiKey**"
$EncodedCredentials = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(("{0}:{1}" -f $APIKey,$null)))
$HTTPHeaders = @{}
$HTTPHeaders.Add('Authorization', ("Basic {0}" -f $EncodedCredentials))
$HTTPHeaders.Add('Content-Type', 'application/json')

#API v2 URL
$URL = "https://mycompanydomain.freshservice.com/api/v2/tickets" 
  

$Attributes = @{}
$Attributes.Add('description',"Test description, please disregard.")
$Attributes.Add('status', 2)
$Attributes.Add('subject',"Powershell ticket creation test")
$Attributes.Add('priority', 1)
$Attributes.Add('email',"mycompanyemail@mycompany.com")
$Attributes.Add('group_id', **groupId_integer**)
$Attributes.Add('responder_id', **responderId_integer**)
$Attributes.Add('category', "Software")
$Attributes.Add('source', 2)
 
$JSON = $Attributes | ConvertTo-Json
$JSON
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
Invoke-WebRequest -Uri $URL -Headers $HTTPHeaders -Body $JSON -Method Post -ContentType "application/json"

current error:
description : Validation failed
errors : {@{field=responder_id; message=Invalid responder_id; code=invalid_value}}

If I leave out the group_id (same applies to leaving out responder_id) I get this error:
description : Validation failed
errors : {@{field=group_id; message=It should be of type Positive Integer; code=missing_field}}

So I have the following questions:

  1. I’ve tried ID’s of different agents in our system, all to no avail, how can I retrieve valid responder_id’s?

  2. According to the API V2 documentation neither group_id or responder_id are mandatory by default, what makes group_id and responder_id mandatory?

I have not tried the above using curl yet, but I am expecting the same errors tbh.

Any help on this issue is greatly appreciated!

1 Like

Hello @eriknettekoven, have you verified that the responder_id’s that you are using are agents who belong to the group identified by the added group_id attribute? Perhaps the agent (responder) is not assigned to that group. Just a thought.

Take care!

Hi @Zach ,

Thank you for your reply, as I stated in my case:
One time it give a different error: not part of group_id (or something like that), which made sense as the id used was indeed not member of the used group_id.

But even after using a responder_id that is part of the group_id it keeps returning above error.

Do you maybe know a way on how to verify the group_id and it’s members and then with their integer responder_id’s? I verified by checking in the web portal, but getting an export of some sorts would be awesome.

Never mind, was already able to use GET commands to get the group_id’s and agent_id’s. Problem still not resolved though.

Regards,

Erik

1 Like

Hi @eriknettekoven,

Yes it is my understanding that agent_id and responder_id are the same. If you were to remove that field, are you able to create a ticket without an agent assigned to it? Are the credentials you are passing in for authorization an Admin agent?

-Zach

1 Like

Hi @Zach,

The API key I am using is the API key from my account and I my account has the Admin role.

And also as stated in my case:
If I leave out the group_id (same applies to leaving out responder_id) I get this error:
description : Validation failed
errors : {@{field=group_id; message=It should be of type Positive Integer; code=missing_field}}

That’s also the reason why I am wondering, what makes the responder_id and group_id mandatory?

Hey @eriknettekoven,

Yeah the group_id and responder_id should not be mandatory. I wonder if passing “null” would work, probably not if the error is looking for a positive integer. Let’s rope in some of the DevRel team @Saif @kaustavdm for a little assistance.

Sorry I wasn’t much help :frowning:

Take care,
Zach

Hey @Zach ,

No worries, your input is still appreciated. And I did make some progress!

If I use Invoke-RESTMethod instead of Invoke-WebRequest, the ticket gets created!

Both the fields group_id and responder_id are still mandatory. To make it more interesting in the ticket that is created only the group_id field is actually filled, the responder_id is still empty. Which makes it even more weird the fields being mandatory… :thinking:

2 Likes

This could more likely be a bug. Is it reproducible? @eriknettekoven

@Saif
Well I can run the script as many times as I want and the issue stays the same. Does that make it reproducible?

Ideally, I would like to only use the fields that are also stated as mandatory in the API V2 manual, and not be surprised by other suddenly mandatory fields. Now the manual could be updated to reflect the other mandatory fields when using PowerShell, but I rather do not assign a group and/or agent when creating the ticket using powershell. It should be the same as when a user creates a ticket via the portal; neither a group nor an agent is assigned when they do so.

With my limited expertise, I would say this is a bug when using powershell to talk to the v2 API, but I could be wrong.

EDIT:
Or could it be that the API key I am using, is an API key from an Agent, and when agents create tickets the group_id and responder_id are actually set to mandatory in the settings of freshwork. Will test with a user account to see what happens.

EDIT 2:
Although not (yet) clearly stated in the documentation, only Agents get API keys, users do not. So testing with a regular user acccount is not possible.

@Saif
Can you confirm this is a bug or by design?

And with by design I mean that creating tickets using powershell it needs to follow the rules set for agents; if other fields than the defaults have been configured as mandatory, I have to include those fields in the scripted ticket creation as well?

1 Like

There is one way we can confirm this.

Do you mind using a tool like Postman to create tickets with fields that are non-mandatory? If ticket creation works with the Postman and fails with the script… we will have to revisit the script.

1 Like

Hi Saif,

I’m open to use any tool to troubleshoot, where do I get this postman tool?

Hey @eriknettekoven https://postman.com is what @Saif is referring to. Lets you make API requests using a gui interface. A wonderful tool to add to your toolkit. I use it all the time so let me know if you need any assistance regarding its use with freshservice APIs.

Take care!

Thanks! I will have to get back to you guys on the progress on Monday. Please bear with me :slight_smile:

@Zach
Ok, I could not resist on taking a look already. First impression; looks nice, but I have NO clue how to use this as troubleshooting tool with freshservice. :disappointed_relieved:

Or actually running into the ‘not authorized’ part and not sure how to get that authorization fixed getting records from the url.

1 Like

No problem! I can help with that.
This is a great tool to troubleshoot freshservice in this instance because if we can get a successful API POST request then it would indicate that something may be wrong with how Freshservice is handling PowerShell scripts or that there could be something wrong with the written script itself

To replicate the “Create Ticket” request in postman make sure you are set up like this


Then you will want to click on Authorization to set this value. For type you can use Basic Auth, and set your admin api key in the username field and a “X” in the password field (I am not sure why it has to be setup this way, but this is how I have found it to work best. Maybe @Saif can explain this better).

Then in the body select “raw” and JSON as the type of text and enter the mandatory fields from the documentation for creating a ticket.

Then all you should have to do is click the “Send” button to make the request. What will come back in the response is the payload of the ticket or any errors during the request.

Hope this helps some!

2 Likes

That was really helpful, you’re the best! Unfortunately, same error as when using powershell.

image

2 Likes

@eriknettekoven these errors are actually helpful. Should indicate that your powershell script is legit and it is something else causing the problem.

Here is a thought I had… When you navigate in freshservice to Admin > Field Manager > Form Fields do you, by chance, have Agent or Group marked as required when submitting the form?


This could be why they are indicating mandatory when using the API.

Thanks for confirming, @eriknettekoven and guiding @Zach

I informed the Freshservice API engineering team about this incident. Let’s wait for them to come back with confirmation.

1 Like

@Zach That is what I was trying to point out in my earlier reply to Saif here. And to answer your question, Yes the behavior for agents is set to required for both the fields reporting errors.

So it looks like the API is held to the same constraints as agents are. Which makes sense as the API is from an agent, but it is not desirable and as far as I know not documented as such. I would like to be able to create a ticket via script, but without the same constraints set on agents. Not sure if that is possible in the current situation.

@Saif above might be important to note for you as well?

1 Like