Today, we are launching v201311 of the DFP API. This release includes improvements to location targeting and expanded PQL functionality. It is the final version to allow ClientLogin and OAuth1.0 authentication, and provide support for the old Java client library. A detailed list of these features and what’s changed can be found on our release notes page.
It’s all about location, location, location
Starting in v201311, we are making an important change to how you interpret targeted locations; Location objects will no longer come back as subtypes. Instead, they now contain a type field that indicates what kind it is. Since this field is a string, you can now handle new types as they are introduced, rather than having to update to a newer version of the API. This means faster turnaround times to get features into the hands of your customers. A displayName has also been added to easily show your users what is being targeted, just like our UI does. Note, there is no change to how you target locations, and all fields except for id remain read-only.
We believe this is a positive step forward as we continue to streamline the API; the switch to a single Location object aligns with the recently released Geo_Target table and reduces the number of code paths of your application. Stay tuned for a follow-up blog post about best practices and how to migrate your application.
More through PQL
As mentioned in our previous release post, the new LINE_ITEM table provides a quick and easy way to fetch information about your line items. Today, we are releasing the AD_UNIT table to do the same for your inventory. We’ll be releasing more tables soon, so be sure to let us know in the forum what tables you’d like to see next.
One of our popular feature requests is the ability to filter reports by parent ad units, i.e. by sections of your inventory. Now, with the AD_UNIT_ANCESTOR_AD_UNIT_ID dimension, you can filter by any ad unit within the inventory hierarchy. See the RunInventoryReport example in each client library for more.
We've also updated the ActivityService to no longer require an activityGroupId in PQL filter statements. We've updated our GetAllActivities example to reflect this as well.
Deprecation announcements
As we stated in our previous blog post, v201311 will be the last version to support the ClientLogin and OAuth1.0 authentication mechanisms. Starting in 2014, new versions will only support OAuth2. As you plan your application updates for the new year, please take this into consideration.
Finally, if you are a Java developer, v201311 will be the last version supported by the old Java client library. If you haven’t migrated to the new Java client library yet, now would be a great time to do so.
As always, if you have any suggestions or questions about the new version, feel free to drop us a line on our Ads Developer Google+ page.
- Adam Rogal, DFP API Team
It’s all about location, location, location
Starting in v201311, we are making an important change to how you interpret targeted locations; Location objects will no longer come back as subtypes. Instead, they now contain a type field that indicates what kind it is. Since this field is a string, you can now handle new types as they are introduced, rather than having to update to a newer version of the API. This means faster turnaround times to get features into the hands of your customers. A displayName has also been added to easily show your users what is being targeted, just like our UI does. Note, there is no change to how you target locations, and all fields except for id remain read-only.
We believe this is a positive step forward as we continue to streamline the API; the switch to a single Location object aligns with the recently released Geo_Target table and reduces the number of code paths of your application. Stay tuned for a follow-up blog post about best practices and how to migrate your application.
More through PQL
As mentioned in our previous release post, the new LINE_ITEM table provides a quick and easy way to fetch information about your line items. Today, we are releasing the AD_UNIT table to do the same for your inventory. We’ll be releasing more tables soon, so be sure to let us know in the forum what tables you’d like to see next.
One of our popular feature requests is the ability to filter reports by parent ad units, i.e. by sections of your inventory. Now, with the AD_UNIT_ANCESTOR_AD_UNIT_ID dimension, you can filter by any ad unit within the inventory hierarchy. See the RunInventoryReport example in each client library for more.
We've also updated the ActivityService to no longer require an activityGroupId in PQL filter statements. We've updated our GetAllActivities example to reflect this as well.
Deprecation announcements
As we stated in our previous blog post, v201311 will be the last version to support the ClientLogin and OAuth1.0 authentication mechanisms. Starting in 2014, new versions will only support OAuth2. As you plan your application updates for the new year, please take this into consideration.
Finally, if you are a Java developer, v201311 will be the last version supported by the old Java client library. If you haven’t migrated to the new Java client library yet, now would be a great time to do so.
As always, if you have any suggestions or questions about the new version, feel free to drop us a line on our Ads Developer Google+ page.
- Adam Rogal, DFP API Team