Well, I have to use curl. Is there a difference in the way how conduit parses the args?

I think there's a way to send raw json using curl, but if you go to the conduit app and invoke it, you get an example at the bottom of how to repeat the request using arc or curl.
It looks like curl is using some http-query-magic way to encode the request. You can maybe try -d <raw json> with -H 'Content-Type: application/json' instead, it might also work.

I think there is an issue with appliction/json data. If I Provide the data with a valid api.token Conduit returns:

The Request itself looks like: (tested against https://httpbin.org/post)

Results with your suggested JSON:

Yeah, that looks like it's ignoring the encoding, and considers the whole argument as a parameter name.

The relevant task is T5955, which is still open, but maybe this is a bug.

Does the other form works?

No unfortunately not. Doing RestAPI like web request with Powershell is a real pain in the as. JSON Strings doesn't work with some structures. Powershell JSON Conduit Discussion.

So the only way would be to get it running as 'application/json' content type.

It sounds like a legitimate bug or feature request ("making conduit calls from powershell"). Did your Ponduit library used to work and then broke when Phabricator changed something?

It looks like a problem with simple JSON String and complex containing maps / array. I noticed it while using the conduit method pages itself seeing the different json syntaxes like:

$ echo '{
  "names": [
    "T1000",
    "T1002"
  ]
}' | arc call-conduit --conduit-uri https://secure.phabricator.com/ --conduit-token <conduit-token> phid.lookup

and

$ curl https://secure.phabricator.com/api/phid.lookup \
    -d api.token=api-token \
    -d names[0]=T1000 \
    -d names[1]=T1002

In addition to that it seems not quite clear which syntax to use with powershell (or other foreign clients) and which content type should be used. So for powershell it seems like there is a limitation (or issue) for JSON strings when using the default context type application/x-www-form-urlencoded.

In the given Example it seems to work with powershell clients and the following JSON style:

{
 "api.token" : "api-XXXYYZZ"
 "name[0]" : "T1000"
 "name[1]" : "T1001"
}

But again, it's hard to transfer this style for conduit methods like. maniphest.edit-> Transaction commment, where you need nested arrays...

It's hard to debug if your're not a JSON and HTTP Request expert ^^

Finally I found a workaround! Conduit requests from foreign clients have to use the cURL form!
For example if I use the maniphest.edit for adding comments via powershell:

• Request:

• Response:

A litte bit strange seems to be the content type detection. I'm not sure if this is the underlying issue. Maybe it's a powershell, phabricator or httpbin thing: httpbin says it's a application/x-www-form-urlencoded and powershell/phabricator detects it as application/json