Can you walk me through your use case in more detail? We've never seen interest in this, and I can't come up with reasons why this would be useful offhand.

Sure.

We trying to automate Harbormaster + Herald setup for new repositories in our company (have plans to provide Harbormaster API methods soon). This method is required to check if specific rules are not created yet.

Providing 1 for needConditionsAndActions and few additional parameters gives us pretty useful subset.

What kind of rules are you duplicating across repositories? Why can't these rules be expressed as a single rule which affects all the repositories?

Each rule has different parameters in steps. In our case it is different HTTP Request URL.

You can parameterize the URL, in a build step, e.g.:

http://buildserver.com/?repository=${repository.callsign}

Is that not sufficient? How do the URLs vary?

We are providing different tokens for each URL.
And this parameter is not stored on Phabricator :-(

Can you make a single call to some kind of middleware which looks up the token based on the callsign or ID, then submits the request to the build server?

We could also add a custom field support for the token to Repositories, although this is probably some ways away.

Or we could make the build variables extensible, so ${repository.customtoken} would work.

Copying plans and Herald rules for each repository feels sketchy to me. I'm not interested in bringing herald.queryrules or similar upstream until there's a good use case for it (and/or we complete T5873), and this doesn't feel very good to me.