In the past, we’ve thrown AUTHENTICATION_FAILED errors as API exceptions whenever an OAuth2 access token was invalid, expired, or missing. Starting on the release date of v201608, the DFP API will reject these requests as HTTP 401 errors (unauthorized access) instead of as API exceptions for all versions.
If you really break it down, this is a win-win for everyone involved. You don’t waste application quota on authentication requests that are already going to fail, and we can focus on doing what we do best, responding to valid API requests.
What does this mean for you? That’s a bit trickier. If you’re catching the old authentication errors raised by our client libraries, then you’re going to want to shift your integration to catching HTTP errors instead. Since our client libraries are implemented with language-specific practices in mind, you’d be looking for these new occurrences to show up as either errors raised by the underlying HTTP or SOAP libraries or wrapped HTTP errors in the libraries themselves. These failures are generally deterministic and require user action - either to generate a new refresh token, to add a new API user, or to create a valid client - so this is mostly a shift in where to catch the exception rather than wrapping with retry logic.
As usual, if you have any questions or just want to talk about API things , let us know on the developer forum .
Nicholas Chen , DFP API Team
