Api: input parameters were invalid on POST GroupV2/Search/

[nwsm]

Attempting to submit POST requests to group search with:

POST /Platform/GroupV2/Search/ HTTP/1.1
Host: www.bungie.net
X-API-Key: redacted
Content-Type: application/json
accept: application/json
Cache-Control: no-cache

{
  "name": "name",
  "groupType": 1,
  "creationDate": 0,
  "sortBy": 0,
  "groupMemberCountFilter": 0,
  "localeFilter": "",
  "tagText": "",
  "itemsPerPage": 100,
  "currentPage": 0,
  "requestContinuationToken": "false"
}

I have tried a variety of options for the body parameters but can't get it to return anything other than

{
    "ErrorCode": 18,
    "ThrottleSeconds": 0,
    "ErrorStatus": "InvalidParameters",
    "Message": "The input parameters were invalid, please enter valid input, and try again.",
    "MessageData": {}
}

Can anyone please give me an example set of working body parameters?

[vthornheart-bng]

Oy, so this is utterly undocumented, which I need to fix. But GroupSearch basically has two totally different modes for historical reasons. (the interesting TL;DR is that Clans in Destiny used to be an entirely Bungie.net-centric concept, a subset of Bungie.net Groups. When we moved to Clans being an actual in-game concept we shoehorned it into the existing Groups API for backcompat, but many things were not actually compatible... hard lessons learned)

When you're searching with groupType = 1 (Clans), you cannot pass groupMemberCountFilter, localeFilter, or tagText. All of them have to be null or not passed at all, such as:

{
"name": "name",
"groupType": 1,
"creationDate": 0,
"sortBy": 0,
"itemsPerPage": 100,
"currentPage": 1
}

I'll add this to the documentation to hopefully help clarify that in the future: it is extremely confusing, I had to dig into the code myself to figure out why your request wasn't working. :) heh

[vthornheart-bng]

Added it to the documentation for the next time we generate it!

[nwsm]

No problem! Thank you. I'm glad I wasn't going crazy.

[vthornheart-bng]

Aye, I'm glad you brought it up - I never realized just how inscrutable that API had become with those changes. Yuck.

There are across the board improvements that I'd like to make someday, if we weren't so understaffed: it's perpetually at the bottom of the backlog, but I'd love to start returning more specific error messages for invalid parameters. In some places we do, but it's extremely inconsistent: and in places like this, it'd have made the situation at least a little less mysterious.