REST Models PUT invalid JSON request bodies.

I’m working on a two-way bridge between an external API and Skuid by using a REST model. I’m able to successfully ‘GET’ data, however 'PUT’ing data back to an endpoint from the same API doesn’t work.

I am able to issue a working PUT from Postman with the same basic Authentication I’m using through Skuid. The HTTP request as generated by Postman looks like this (sensitive info redacted with x’s):

PUT /rest/v1/subscriptions/xxxxxxxxxxxxxx HTTP/1.1Host:
Content-Type: application/json
Authorization: Basic xxxxxxxxxxxx
Cache-Control: no-cache
Postman-Token: 1dc95f2a-d0cb-7203-2d65-fe2f75176cd3
    "notes": "New Note"


  "success": true,
  "subscriptionId": "xxxxxxxxxxxxxxxxxxxxxxx",
  "totalDeltaMrr": 0,
  "totalDeltaTcv": 0

What I’m able to get skuid to send looks like this:

POST /apexremote HTTP/1.1
Connection: keep-alive Content-Length: 708 X-User-Agent: Visualforce-Remoting Origin: []( "Link https//skuidcs28visualforcecom") X-Requested-With: XMLHttpRequest User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10\_10\_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36 Content-Type: application/json Accept: \*/\*
Referer: [\_\_ui?page=Test]( "Link https//skuidcs28visualforcecom/apex/skuid\_\_uipageZuora\_Test") Accept-Encoding: gzip, deflate, br Accept-Language: en-US,en;q=0.8 Cookie: \_mkto\_trk=id:164-HZR-790&token:\; BrowserId=jsOTxP84TI-j4z2Ob1VX-Q; sid=00D230000000REh!AQwAQAQpvz00CRgygDBNdWN\_Er0VQKjEVXCyfcjsLCSXX7drIAZtMshI5hZCBFzgsRg8h4cYAm1i4QfcxON48DtpRC\_7vuyY; sid\_Client=3000000YIvE30000000REh; clientSrc=; inst=APP\_23

{"action":"skuid.RemotingStubs","method":"proxy","data":["{""url"":""["",&quo...]( "Link https//apisandbox-apizuoracom/rest/v1/subscriptions/2c92c086567df81d015693184d611df3headersUser-AgentMozilla/50") (Macintosh; Intel Mac OS X 10\_10\_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36"",""Content-Type"":""application/json""},""method"":""PUT"",""modelService"":""Subscription"",""contentType"":""application/json"",""body"":""{\""notes\"":\""Test NEW subscription from z-ruby-sdksadas\""}""}"],"type":"rpc","tid":4,"ctx":{"csrf":"VmpFPSxNakF4Tmkwd09DMHlNRlF4TmpvMU56b3lPUzQxTkRCYSw5TW4wS2h6TVhWQjk2SGlzVzhGNVRJLFpHUTJOR0l4","vid":"066230000004PzC","ns":"skuid","ver":36}}


[     {  
      "result":"{""statusCode"":200,""status"":""OK"",""setCookies"":null,""headers"":{""Content-Type"":""application/json;charset=utf-8"",""Date"":""Wed, 17 Aug 2016 16:59:40 GMT"",""Content-Length"":""184"",""Expires"":""Wed, 17 Aug 2016 16:59:40 GMT"",""Pragma"":""no-cache"",""Connection"":""keep-alive"",""Server"":""xxxxxxxxxxxxx"",""Cache-Control"":""max-age=0, no-cache, no-store""},""error"":null,""body"":""{\n  \""success\"" : false,\n  \""processId\"" : \""xxxxxxxxxxxxxxx\"",\n  \""reasons\"" : [ {\n    \""code\"" : 50000000,\n    \""message\"" : \""Cannot extract parameter (Map body): no Content-Type found\""\n  } ]\n}""}"

Now, I’m aware that Skuid sends this off to an Apex class that in turn submits the request. And it would seem that the body/payload it sends off isn’t understood by the API. The response claims there is no ‘Content-Type’ found, which could be a cause of this, or the JSON could be malformed.

My Skuid model’s update looks like this:

Has anyone had any issues with malformed JSON PUT payloads from a REST model?

Hi Henry,

We talked about this offline, but I wanted to update this for the Community.

The issue you’re seeing is a bug in Skuid with the “Basic HTTP Authentication” type. It is not correctly sending the Content-Type header when run through the Apex proxy. This is slated to be fixed in an upcoming patch of Skuid. Thanks for finding this!

For anyone who wants to overcome this before the patch is released. Navigate to ‘Data Sources’ in the Skuid settings. And change the Authentication Method to 'No Authentication.

Next expand the “Headers to send with every request” tab and add an Authorization header. The value will be the word ‘Basic’ followed by your username and password separated by a colon then Base64 encoded.

To achieve this go to and encode:


Where username and password are replaced by the values you would have populated in the Basic Auth. Ensure you don’t forget the colon.

Now you can add whatever headers in addition to the Basic Auth you’d like to have included.