Backendless API call to DELETE


Wondering if I can get some help. We are trying to DELETE from a table using the objectID. I keep getting a 400 error that looks like the following:

{“code”:8002,“message”:“Could not parse request with message: Error decoding json body: null, status code 400, headers DELETE /68610763-2CAC-34B5-FF4F-351A59574400/8DB4CE8C-53E8-EB49-FFAA-DE2A92752C00/data/UserCoupons/7E248572-4267-692C-FF31-2D5F0BE47700”,“errorData”:{}}

I have also tried to delete using a API bulk call and where statement. Also resulted in similar message.

@markpiller Wade thought you might be able to assist. Thanks


Hey David… Might be valuable to have a look the delete call from the perspective of your Swagger file.

@markpiller do you know of anything special or particular a user needs to look into when performing DELETE calls towards Backendless or is it pretty straightforward?


A walk thru of how I have dropsource set up and the failure of the call


Hey David. Thanks for the handy video showing this. I’d like to pull the app down and test to ensure the request is including a correct object ID in the request parameters itself. If we’re getting a code 400 back, that makes me wonder if some of the data might look like it’s heading to Backendless but maybe it’s actually not setup somehow.

Can you share with me a good Build ID of your project so I can pull it down locally?


@wade here is the build ID 1171769338091884347


Thanks for the Build ID. I dug into the code and stepped through the delete request and response (that video was excellent to get right to it all so thank you for that).

Basically from the Dropsource perspective… you’re doing everything correct. I see the DELETE request, and the expected object ID is heading to Backendless. Backendless is receiving it and it’s reporting back an error code 400. From Dropsource POV, we’re doing what’s expected and reacting to the API saying that it can’t do something with what we sent.

I would now troubleshoot this from the Backendless POV and test it out with performing a DELETE request and then catching that request on your Backendless side to see what it’s trying to do with the request to see why it can’t perform as expected. That’s probably the next step in troubleshooting here because from what I can see, you’re all setup correctly from the Dropsource perspective. I see the request succeeding and holding the correct parameters and I see the response error code from Backendless. See what’s happening on the Backendless side that producing the need to submit back an error response and you might find where this isn’t jiving. Perhaps you’re trying to account for a different datatype or parameter expectation isn’t aligned in your Swagger file for the call or something.


Wade - Still not finding the issue. I went back to the app and ran a DELETE and it failed. I copied the the following from the developer console and ran it in postman and it was successful.

The backendless guys say its not on their end.


Did you verify in backendless if that object id exists? The error is saying the id you’re trying to delete in backendless isn’t available to delete.

I’m not sure how this on Dropsource with an error like that. Are you certain you are sending the correct “object Id” back then?

Maybe you sent that delete call successfully with Postman and then when you try it with Dropsource it doesn’t work because the object was deleted the 1st time with postman so it can’t be re-deleted a 2nd time since it’s no longer available after the 1st time?


@wade Here is a quick video.

Here is what is in the video

  1. Run app and login
  2. Create a new coupon with shows up in backendless (I think I forgot to show the db, but it is showing up) you can tell from the quarry that is made.
  3. Try to delete from drop source
  4. Copy url from original dropsoucre request and paste in postman and run. item is deleted
  5. Verification of delete from database



Got a message back from @markpiller

Looks like they can ID issue and are asking dev team for a fix.

@David Brotton I was able to figure out what causes the problem. It is the Content-Length request header. I will discuss it with the development team to see if this is something we can ignore for the DELETE requests


That’s a relief to hear, @david.brotton. Thanks for the update.