Some resources like user groups, external user groups, and architectures are not scoped by taxonomies, yet the the api endpoints associated with these resources accept the `organization-id` and `location-id` options. I didn't observe any effect of these options on the api call, except for when trying to create an external user group and providing either organization-id or location-id, which causes the action to fail and an error appears in the logs: undefined method external_usergroups for #<{Organization/Location}: ...

There is, however; no simple way of fixing this. All `Api::V2` controllers inherit from `Api::V2::BaseController`, where the taxonomy options are added through the `resource_description` method from Apipie. While this method can be overridden in child classes, there appears to be no way (at least I have not found such a way) of removing a parameter once it is added. This probably reflects the standard inheritance behavior, so whether the option of removing a parameter should be added to this method is debatable.

The most correct solution would be of course to create a child class inheriting from BaseController, provide the resource description with taxonomy options there, and then have all taxonomy-scoped resource controllers inherit from it. The problem is that there are many plugins in which the controllers inherit from BaseController that would all need to be updated as well. I see too much potential for breaking because of a relatively harmless bug, so in my opinion the risk is not worth to fix the issue this way.

Hence, I propose a partial solution. Hide the taxonomy options from the API documentation of the relevant resources. This is possible with overriding the `resource_description` method in the relevant controllers. Hammer can also be updated to not display options with the `show => false` flag set.

This would not completely solve the issue but in my opinion has the best effort/result/risk reduction ratio.