This issue was reported in https://issues.jenkins-ci.org/browse/JENKINS-16639  and seems to  have been resolved in 2013.

However, I am facing the issue with exact same symptoms using Jenkins 2.150.3 and extended choice parameter plugin 0.76.

The following is an approximate cURL equivalent, because I am using python requests library to do the POST 

curl -X POST https://<JENKINS_URL>/job/xyz/buildWithParameters --data {"json": {"parameter": [{"name": "option1", "value":"value1"}, {"name":"text1", "value": "value2"}]}} 

The Python code from which the above curl was derived is shown below:

requests.post("https://<JENKINS_URL>/job/xyz/buildWithParameters", 
             auth=(<USERNAME>, <PASSWORD>),
             data={'json': {'parameter': [{'name': 'option1', 'value': 'value1'}, {'name': 'text1', 'value': 'value2'}]}}
             )

where 'option1' is the name of the extended- choice-parameter (radio buttons), and the 'value1' is the string value associated with the particular choice

The Jenkins job gets started (following along on the Jenkins UI) but quickly fails with 

/tmp/jenkins4137547693282782703.sh: line 9: option1: unbound variable 

To confirm that the parameter is indeed not being passed, I click on the job id in the Jenkins UI, and click on Parameters from the options in the left pane, and "option1" is missing, whereas  "text1" is there and is correctly set to "value2"

However, the same job run from the Jenkins UI proceeds to completion, the job URL is of course different

https://<JENKINS_URL>/job/xyz/build?delay=0sec

In fact, if the above curl operation is run with https://<JENKINS_URL>/job/xyz/build instead, it also proceeds to completion. However, only when the URL has buildWithParameters does it return the correct `Location` header in the response with the URL of the queue where the job can be monitored as it is running. This bug is blocking our automation efforts.