bannerColor WARNING_YELLOW templateName stackForums

Debugging API Calls

Using the API should be straightforward and it should "just work", but there are a lot of moving pieces in most applications and it can sometimes be challenging to figure out how to find the reason why something's not working.

While we suggest that people use a LinkedIn library wherever possible, this can obscure the actual HTTP traffic which has the information you need to debug issues with your calls.  Ideally, those libraries will provide some sort of debugging mode for this process, but when that's not available it's helpful to understand how the calls themselves work when errors are being sent. If you're having issues with Authentication you should also check out Common Issues with OAuth Authentication.


Many questions can be answered in the developer forums or documentation, but when you need help troubleshooting a specific issue, we need several pieces of information in order to give you the best support experience.

We need all the information from the Logging section.  We need to know the library or language you're using.  Sample code is frequently helpful (but at the very least we need to know exactly what URL you're calling), and what you're expecting to get back in return.


Our servers handle millions of requests, so from our end it's frequently time consuming to find what's happening if the application starts behaving in an unexpected way.  When an error is returned, our servers return information in the header and message body that clarify the issue.When this happens, it's extremely useful for us to have the following information about the calls:

  • Full URL
  • All request headers (particularly the Authentication header)
  • Response headers (particularly any oauth_ headers)
  • Response body

This can be helpful for you to understand why a request is failing, and if you need to escalate to our team, it'll help us find the answer much more quickly.

The full URL, if using query parameters for OAuth, looks like this (broken onto separate lines for readability),Sr_hCzLJkL,jkzOHaJWTT,eib2h4D_OG,iirBq2x3XI):(relation-to-viewer)?

If using headers for OAuth, you'll be sending an Authorization header that looks like this:

OAuth oauth_nonce="ET6UgZgSxi3bP1yEn4wJYSS9iGijbFr0lCS9bk6TiPc", oauth_signature_method="HMAC-SHA1", oauth_timestamp="1304552130", oauth_consumer_key="1iK9RUZ1FLJaLUpp90xztjhJXLkdTooiNqXMAORUrpoWJaR0cozd863qyIwvb0ZJ", oauth_token="3df261cb-0532-4015-8618-01b0a41cd45e", oauth_signature="tC2kXzRIZIL6fw%2BWYCZxTxEHWuE%3D", oauth_version="1.0"

In either case, the authentication pieces are frequently important for debugging issues.  You should also capture the "x-li-format" header (if set) and the "Content-Type" header.

Most languages and libraries have ways to examine the header information for the request and response object.  During development, it's sometimes useful to use an HTTP Sniffer (such as HTTPScoop for the macintosh or Fiddler for the PC).

Even when an error is returned, the server frequently returns a useful message to help debug the problem.  Many libraries don't present this by default, but logging and checking this message whenever you get an error is an excellent way to get started debugging unexpected problems.

Example response headers:

  'status': '401', 
  'content-length': '293', 
  'transfer-encoding': 'chunked', 
  'vary': 'x-li-format,Accept-Encoding', 
  'server': 'Apache-Coyote/1.1', 
  '-content-encoding': 'gzip', 
  'date': 'Wed, 04 May 2011 23:21:18 GMT', 
  'x-li-format': 'xml', 
  'content-type': 'text/xml;charset=UTF-8'

Example response text:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <message>[unauthorized]. No consumer found for key 11iK9RUZ1FLJaLUpp90xztjhJXLkdTooiNqXMAORUrpoWJaR0cozd863qyIwvb0ZJ</message>
Or for a timestamp issue:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <message>[unauthorized]. safety zone - expired at 1304540900000</message>

HTTP Sniffing

If you haven't done work with HTTP requests before it can be tough to get some libraries or languages to show information about requests and responses.  There are HTTP sniffers you can install on your system to watch the HTTP traffic and these can be helpful when developing and/or debugging.  For the Mac, HTTPScoop works quite well (although it doesn't see HTTPS traffic).  For the PC, Fiddler is a great choice.