Your data. Anywhere you go.

New Relic for iOS or Android

Download on the App Store    Android App on Google play

New Relic Insights App for iOS

Download on the App Store

Learn more

Close icon

API error when JSON keys contain incorrect case



Please paste the permalink to the page in question below:

Please share your question/describe your issue below. Include any screenshots that may help us understand your question:

I’m trying to use the API to post an application deployment record with a description that contains a newline/line break character. I can get it to work without the newline, but the API returns an error (usually a 500 server error) whenever I try to use \n within my description string. For example, this JSON causes an error:

	"deployment": {
		"revision": "4a08ab5",
		"Description": "CircleCI deployment for:\nPOWR - 1676 Log deployments to New Relic ",
		"user": "RichardDavies"

Error screenshot

Although that JSON is valid, the \n is causing an issue with the API for some reason. So how do I encode a newline in a JSON string that will work with your API?


Hi, @rick.nixon: Interestingly, it works for me:

But it looks like the Deployments UI will not show the description on multiple lines:


Hmm… weird. So I’m trying to use that API tool to reproduce and isolate an issue I’m having in my code where sometimes the API works, and other times I get an 500 error. I thought I had it narrowed down to the newline \n, but after further investigation apparently that’s not it.

So here’s what I know as of now. If I start with the default JSON template in the API tool and modify it with my own data, it works fine (even with the \n as you discovered.) However, if I copy the JSON code snippet from my original post n my browser, and then paste it into the API tool, it seems to always fail, regardless of what the actual JSON is.

It seems perhaps there’s some special non-printing characters (such as a newline, line feed, carriage return, etc.) that can mess up the API. But since it just gives a generic 500 error, I have no idea what is going on.


Looks like the code in your original post is indented with tab characters. Try replacing them with spaces. :slight_smile:


I did. I even removed all of the indentation and line breaks and it still errors on my pasted code.


Hmm. Maybe different line break characters (LF vs. CRLF)? I would suggest using an editor that displays non-printing characters, and compare the JSON that works with that which causes an error.


Doh! Somehow my code snippet in my original post ended up with a capital D in the description key. :man_facepalming:

Although I’ll take the blame for that mistake, the API should return a more helpful error message in that case instead of a generic 500 error. (For example, you get a helpful error message if you omit the revision key, and technically, the description key was omitted in this case as well.)


Fully agree here @rick.nixon - we’ll get the feedback passed on for better error messages. :slight_smile:


The reason you get a helpful error message when revision is omitted is because revision is a required value; description is optional. I agree that a generic 500 error is not helpful, but I would argue that the API should not return an error if you provide an unknown value; the value should simply be ignored.


I agree that a generic 500 error is not helpful, but I would argue that the API should not return an error if you provide an unknown value; the value should simply be ignored.

Ah, yes, you are right. Since the value is optional, it should simply be ignored (and should not cause an error either.)

But one case where the error handing could be improved is for invalid JSON such as the following which contains a multi-line string (which is not allowed in JSON):

   "deployment": {
      "revision": "4a08ab5",
      "description": "CircleCI deployment for:

POWR - 1676 Log deployments to New Relic",
      "user": "RichardDavies"

That JSON will cause a 500 error with no explanation. Even a simple “JSON parse error” would have saved me a lot of time trying to figure out why the API didn’t like some of my requests.


Thanks Rick! That feedback has just been passed on.