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

Important REST API Update



Do you use our REST API? You will probably want to read this.

We recently moved RPM’s API behind an internal proxy server that it was not behind before. It’s a vital part of our own move to being on our in-house cloud. The good news? It helps us be more reliable and scalable in order to serve you, our customers, best. The bad news? The proxy server is newer and stricter about following standards for requests and a few things have changed that you should know about.

Change 1: Request URL character limit.

If you’re used to GET sending requests with, say 7,000 characters in a URL, those will no longer work. In general, unbounded URI sizes are not a good idea. Different browsers for example limit them all to different sizes, but 2000 is always a safe bet. For us, the new magic number is 4096 characters. If you’re suddenly getting 413’s, check your request size.

Really need that URL to be megabig? Try using POST instead of GET. POSTs are not limited by size. Or break up your request into two.

Change 2: Enforced URL Encoding

The proxy service is more strict on requiring URL or Percent Encoding. So special characters like “}” or “<” will need to be escaped. It’s worth noting that at this time there may be some URL’s that the API Explorer generates that are not escaped.

How do you know which characters need to be escaped? Why do ()’s still work? There are special characters that have been reserved in RFC 1748. The full list is: “;”, “/”, “?”, “:”, “@”, “=” and “&”.

The list of characters deemed unsafe to reserve by the above RFC are “{”, “}”, “|”, “”, “^”, “~”, “[”, “]”, and “`”. Those characters in a url will need to be percent encoded. If you are seeing unexpected HTTP Status 400 response codes, it’s worth taking a look and seeing if you are using any of the above.

Here’s an example of unescaped vs. escaped {}’s:

Unescaped: {my-cool-parameter}
Properly percent escaped: %7Bmy-super-duper-cool-parameter%7D

Known Issue #1: Mismatched pagination links

Relevant if you send curl requests using “…”First of all, yay for using https! Second of all, you might notice if you are looking at the response headers (the -v option for curl will make those visible in your response) that the pagination links you receive are for the http version of the path.

This is an unexpected change on our part. There are several variables involved and we thank you for your patience with this bug as we determine the best method of fixing it without disrupting service. We will update this thread when we have a suitable fix in place. And, as always, let us know if you have any questions!