As part of our ongoing efforts to improve DFP's performance and stability, we will be introducing limits on select DFP items, beginning June 30, 2014. As an API user, here’s how this change will affect you.

If you create more children than the allowed maximum for an entity, or modify an existing entity so that its number of children exceeds those limits, the API will throw an EntityChildrenLimitReachedError. Refer to the error’s reason field for an explanation for each type of entity that exceeds a child limit. The best way to handle this situation is to catch ApiException errors in your code, check the error type, and perform whatever is appropriate for your application based on the reason.

For a more detailed example of best practices with ApiException errors, please see this blog post on troubleshooting and error handling.

As always, if you have any suggestions or questions, feel free to drop us a line on our API forums or Ads Developer Google+ page.

 - Vincent Tsao, DFP API Team

If you synchronize your line items regularly to a local database using the LineItem.getLineItemsByStatement method, you are hopefully already filtering by LineItem.lastModifiedDateTime and using our other best practices. We want to mention one other best practice that will help you synchronize your line items as quickly as possible.

Recently, DFP has begun to auto-archive old orders. This affects the lastModifiedDateTime field of the line items in the orders. This means that you may suddenly get significantly more line items in one day’s synchronization than in the previous day’s depending on how many orders were auto-archived since your last synchronization. To prevent this, we recommend always filtering by isArchived. For example:

  WHERE lastModifiedDateTime >= '2014-06-01T00:00:00' AND isArchived = false

As always, if you have any suggestions or questions, feel free to drop us a line on our API forums or Ads Developer Google+ page.

 - Vincent Tsao, DFP API Team

Today, we launch v201405 of the DFP API. This release brings better OAuth2 standards, consolidates line item goal information, and adds a lot more report fields. A detailed list of these features and what’s changed can be found on our release notes page.

OAuth2, line item goals, and reports

To align better with OAuth2 standards, starting in v201405 we have removed the OAuth2 SOAP object. This means that you can no longer pass OAuth2 authentication information through the SOAP header. Instead, you pass it in the HTTP header. All of our client libraries have already been updated to follow this process. If your integration is not using one of our client libraries, please be aware of this change when you upgrade to v201405.

We’ve heard your feedback that the line item goal fields such as unitsBought can be confusing. In this version, we have moved line item goal-related fields into their own object, called Goal. This makes it easier to understand and find line item goal information. For example, previously line item goal information would be set as follows (using the PHP client library):

  $lineItem->unitsBought = 500000;
  $lineItem->unitType = 'IMPRESSIONS';

Now this goal information is stored in its own object:

  $goal = new Goal();
  $goal->units = 500000;
  $goal->unitType = 'IMPRESSIONS';
  $lineItem->primaryGoal = $goal;

We’ve also heard your feedback regarding parity between the ReportService and the UI in terms of what dimensions, attributes, and columns are available when running a report. In v201405, we make available a whole slew of new report fields, including Gross Rating Points (GRP), business intelligence, shared selling, and SDK mediation dimensions and columns.

Increased quota for premium networks

Although not specific to v201405, the quota for premium networks has been raised. This means that if you want to limit your requests locally, we now recommend at most 8 requests per second for premium networks. For small business networks, we continue to recommend making at most 2 requests per second. As always, limiting your requests does not guarantee that all your requests will succeed, but will help mitigate quota errors. You should still be writing code to handle EXCEEDED_QUOTA errors. For more information about exception handling and recovery, please refer to this blog post.

Much deprecation, wow, so deprecated

We want to remind you that with each new version release, we’ll also be deprecating a number of older versions. Versions v201206 and earlier have now been turned off. All requests made against those versions will fail. Our next wave of versions to be turned off are v201302, v201211, and v201208. This will occur on August 1, 2014. For more information on this deprecation and what resources are available for migrating to the latest version, please see this blog post.

As always, if you have any suggestions or questions about the new version, feel free to drop us a line on our API forums or Ads Developer Google+ page.

 - Vincent Tsao, DFP API Team