Web_api/api/issues/bulk_change description confusing

I’m using SQ 8.5 using the web API. The documentation on [server]/web_api/api/issues for the bulk_change command only indicates the issues parameter is required; everything else is optional.

I get that SOMETHING besides the issue(s) needs to be specified in order for the command to have any meaning. But when I tried to use it to add the same comment to some issues, I got an error message “At least one action must be provided”. But if I include the set_type parameter, then it seems to be happy – but only if I CHANGE the type; if it’s the same setting, the request comes back “ignored.” Can the documentation be updated to reflect which parameters are truly optional and which require at least one of a set to be included? And is there a simple way to make a bulk change to just the comments of multiple issues?

BTW, is there a limit on the number of issues in the issues string?


To be clear, you’re saying the web service doesn’t work if you only pass issues and comment?

Regarding an issue count limit, I’m sure there are practical limits, but I’m not aware of anything artificially set/enforced.


Yes. I’m specifically referring to the bulk_change function. Here is an example. This is done in PowerShell – unfortunately the variable-width font will mess up the alignment. I’m using one of the PowerShell cmdlets to access the web API.

  1. Here the body only has the comment and issues parameters:

> $paramsbc

Name Value

comment Test
issues AXVL8f2LFgFEXSbGfR1Q

> $response = Invoke-WebRequest -Uri $url -Header $headers -Body $paramsbc -Method Post

Invoke-WebRequest : {“errors”:[{“msg”:“At least one action must be provided”}]}

  1. Now I add the set_type parameter, and get a normal response:

> $paramsbc.set_type = ‘BUG’

> $response = Invoke-WebRequest -Uri $url -Header $headers -Body $paramsbc -Method Post

> $response.Content

So my conclusion is that the call doesn’t work if just issues and comment are set, but adding set_type fixes the problem.

(Note: if you repeat step 2, the counts will change to … “success”:0,“ignored”:1 … because it’s not CHANGING the type – the specified type is the same as it currently is in SQ, so SQ decides there’s nothing to do and ignores the command. But this means you can’t work around this problem simply by setting the type to what it already is. If you want to bulk-add a comment, you could do it by doing step 2 but making sure the set_type parameter CHANGES the type, then doing another bulk change to set the type back to what it was before, without the comment parameter (or else you’d get the comment added twice). But that would be a kludge, and wouldn’t let you work on issues of different types.)


Thanks for the clarification. I’ve referred this internally.


I just hit a limit, which seems to be 500. See Issue count limitation with bulk_change

Hi @MisterPi,

This is indeed an error in our documentation. I’ve opened a ticket here to fix the documentation. I’ve included a link to your feature request as well, so it will be considered when that ticket is tackled.