I imagine you are calling an API in order to get that json payload. I don't know whether you are in control of that API, but what follows holds true in any case.
When you call an API you are basically communicating with a remote resource with which you have agreed some conventions. The fact that the API declares to send you a json response having a certain shape is part of the agreement between you (the API consumer) and the API author. This means that, if the API author has documented that he is able to send you a json payload having a certain shape, then you need to trust him and assume that he will send you that kind of response whenever you call the API.
When you write the code to consume the API remember to send an Accept request header having the value application/json (this is useful when the API is able to serve responses in different formats, for instance json and xml, and supports what is called content negotiation).
When you get a response inspect the Content-Type response header and check whether the response media type actually is application/json. If it isn't, you need to find out a way to handle such an unexpected situation. You can decide to throw an exception for instance, because you are facing an unexpected situation and, probably, there is not a business rule in your application domain to handle it (you were expecting json and you get, for instance, xml. What can you possibly do ? nothing better than throwing an exception probably, because the scenario you are facing is totally unexpected).
Let's suppose you get an application/json response content. Then, you can deserialize it in order to consume it in your application. Don't do that manually. There are several libraries meant to do that; in the .NET space one widely adopted is newtonsoft json. Let the library to deserialize the json you get from the API. In case the string you get is not a valid json, the library will probably throw an exception: that's the right thing to do, again the reasoning is the same illustrated above for the response content type.
If the API returns you an invalid json string, it's not a concern of your own code to fix it, in order to make it valid json. That means that the API author is trying to cheat you, he is not being compliant with the agreement cited above at the beginning of my response. You should let him know that he has a bug, because he is not sending valid json and he should fix it. That's probably a sign that he is not using a proper library to serialize its objects to json.
If you need to validate a string in order to check whether it is valid json, use an online service like json lint.
Long story short: fixing the response content so that it becomes valid json is not a concern of the code meant to consume the API. It's a concern of the API author.
