Hello, DFP API developers! We just wanted to let you know of some minor DFP API changes that affect all versions of the API. Most likely these won’t affect your integration with DFP, but we’re announcing them here for transparency.

Deleted line item creative associations (LICAs) are no longer persisted

Deleted LICAs are no longer persisted in the product. This will affect all versions of the API. There are two things to be aware of as a result of this. First, the method getLineItemCreativeAssociationsByStatement will no longer include these deleted LICAs. Second, if you’re syncing your LICAs daily, you may notice fewer LICAs coming back. As a reminder, you can always use the action DeactivateLineItemCreativeAssociations if you want to keep them around, but not use them. This change is already in effect.

Creative placeholders are no longer assigned an ID

We are also getting rid of CreativePlaceholder.id because it is not used or referenced anywhere in the API. This field will be removed in v201508. For all versions prior to v201508, this ID now comes back as 0, instead of an ID assigned by Google. This change is also already in effect.

If you have any concerns or questions about these changes, you can always contact us on the DFP API forums and we’ll be glad to help you out.

 - Vincent Tsao, DFP API Team

It's that time again - time to say goodbye to another version of the DFP API. In accordance with our deprecation schedule, v201403 has been deprecated and is scheduled for sunset on Tuesday, June 30 2015. At that time, any requests made to v201403 will return errors.

If you're currently using v201403, there's still time to migrate to the latest and greatest v201502. To do so, check the release notes to identify any breaking changes, grab the latest version of your client library, and update your code!

Things to look out for include:

• OAuth SOAP headers are no longer supported. You'll need to pass authentication information in HTTP headers instead. If you're using a client library, we took care of this for you.
• Line item fields unitsBought and unitType have moved into the Goal object.
• The endpoint URL for requests has changed from https://www.google.com to https://ads.google.com. We updated this in the default settings of our client libraries, but double check your local configuration files as well.
• LineItem.startDateTime and LineItem.endDateTime now require a timeZoneID. You can retrieve all the supported time zone IDs from the Time_Zone PQL table.
• The ForecastService got a facelift, including renaming existing methods and adding support for a new kind of forecast.

This is not an exhaustive list, so as always don't hesitate to reach out to us on our API forum with any questions.

 - Chris Seeley, DFP API Team

Now that it’s spring again (in the Northern Hemisphere at least), it’s time for DFP’s annual spring cleaning! In this edition, we’ll be doing some pruning of our ReportService. What does this mean for you? We’re sunsetting some reporting dimensions, attributes, and metrics in existing versions (before the version is fully sunset), so your reports will break if you don’t migrate before the shutoff dates. I know what you’re wondering: “should I panic?”. Absolutely not. This type of behavior rarely occurs, so as long as you phase out usage for these particular fields, you should be fine moving forward.

Merged Metrics

Remember when Doubleclick for Publishers was called DART? I, too, get nostalgic about our old ad server, but it’s been a couple of years since we transitioned to the new DFP platform, and it’s just about time when the merged reporting columns are no longer useful (these columns only existed so you could continue reporting on delivery that spanned DART and DFP). In all versions after v201502, we will no longer provide merged reporting columns and dimension attributes in the API, that is, anything starting with 'MERGED_' or contains '_LIFETIME_MERGED_.' After August 1, 2015, these columns and dimension attributes will stop returning data entirely and will return INVALID_COLUMNS in all versions that still include them.

There are three scenarios in which you’re using these columns:

1. Just for fun.
2. Because you forgot you’re using them.
3. Because you have lifetime line items that have carried over from DART (in which case you’ll have to recreate these). To give you an example, if the metric you care about is impressions, you can get the DART delivery portion by subtracting the portion of delivery from DFP Premium (AD_SERVER_IMPRESSIONS) from the MERGED value (MERGED_AD_SERVER_IMPRESSIONS) which represents the aggregate DART and DFP Premium volume. Additionally, you should make the switch to the non-merged columns and dimension attributes as soon as possible.

Dimension Filters

But wait, there’s more! Our next API version (v201505) will be the last to support some of our infrequently used dimensionFilters.

• MOBILE_LINE_ITEMS
• WEB_INVENTORY_UNITS
• MOBILE_INVENTORY_UNITS
• WHOLE_NETWORK
• PARTNER_STATS_TYPE_ESTIMATED
• ACTIVE_ADVERTISERS
• PARTNER_STATS_TYPE_RECONCILED
• WEB_LINE_ITEMS
• ALL_SALESPEOPLE

In each of the cases above, the filters either no longer provide meaningful information (as is the case with mobile vs. web line items and ad units with platform unification complete), or weren’t being used at all.

Similar to the changes above, after August 1, 2015, these dimension filters will return an INVALID_DIMENSION_FILTERS error in any version that still includes them.

So if you’re using any of the reporting features above, consider this an early heads up (and an opportunity) to refactor some of your code for spring cleaning.

As usual, if you have any questions, comments, or concerns, don’t hesitate to let us know on the forums.

 - Nicholas Chen, DFP API Team

As an avid reader of this blog, you have undoubtedly already seen the announcement that our dear old friend, the client library known as ‘AdsPyGoogle,’ will be sunset on January 5, 2015. Yes—we too at Google are very sad about this.

Fret not! In its place, we have a more than capable replacement in the form of our new GoogleAds Python client library which is more lightweight, has far fewer dependencies, boasts improved utilities and functionality, and perhaps most importantly, supports Python 2.7 as well as 3.x.

If you need a starting point on how to perform this switch, we have a blog post detailing the differences between the two, as well as a nifty migration guide on Github.

As usual, if you have any questions, feedback, or comments, please don’t hesitate to reach out on the DFP or AdWords forums.

 - Nicholas Chen, DFP API Team

This is a friendly reminder that, on February 27, 2015, we will sunset DFP API versions v201311, v201308, and v201306. At that point, requests to these versions will fail. We'll also remove them from our online documentation and the client libraries. If you are currently using one of these versions, this is an excellent time to begin migrating to a supported version. See the release notes for a list of the many new features in our recent API versions.

Going forward, all DFP API versions will follow a consistent deprecation schedule: versions will be supported for one year, deprecated for one quarter, then sunset. This means each of our quarterly API versions will be available for 15 months from the time of release. This deprecation schedule enables us to spend more time improving the latest versions with new features.

Note that v201311 is the last version that supports ClientLogin, which was officially deprecated across all of Google on April 20, 2012. If your application is not yet using OAuth2, you must migrate before Feb 27, 2015.

If this task seems daunting, don't fret, we have you covered. On our Developer page, we have a helpful OAuth2 guide to make sure the transition is as smooth as possible. As an added reason to switch, the DFP API now supports OAuth2 service accounts. You can add service account users directly in the DFP UI. For more information, see here for a guide on how to use a service account user with the DFP API.

If you have any feedback or comments about this deprecation, or the API in general, please feel free to leave them on our forum.

 - Nicholas Chen, DFP API Team

After successfully removing several older versions of the DFP API earlier this month, we’re continuing our 'Spring Cleaning' by reminding everyone that support for version v201302 or earlier of the DFP API will end on August 1st, 2014. If you are still using one of those versions after that date, all requests will fail and your application will cease to work until you migrate to a supported version. Please reference the release notes for all changes to the API when migrating to a newer version.

In addition, please note that ClientLogin support is being phased out and that you will have to migrate to OAuth 2.0 in order to authenticate starting with v201403. Please reference our OAuth 2.0 implementation guide for help with this process.

If you have any questions about this upcoming change or anything else related to the DFP API, please contact us on the forum or via our Google+ page.

 - Nicholas Chen, DFP API Team

Since joining Google Play services back in October 2013, Google Mobile Ads has added support for the following products:

• AdMob
• DoubleClick for Publishers
• DoubleClick Ad Exchange

The new Google Mobile Ads APIs also offer additional features that the standalone Android SDK doesn’t have:

• The new library has full support for the Android Advertising ID, and is compliant with the latest Google Play Ad Policy.
• Google Play services offers automatic service updates via the Google Play store, so you get the benefit of always being on our latest and greatest mobile ads library without the hassle of having to update your apps.
• The DoubleClick Ad Exchange JavaScript adapter is now included in the Google Play services library. This means you have one less dependency in your application, and you can be sure that the adapter will always be compatible with future Google Play services updates.

As part of the Google Play services 4.2 update, we are deprecating the standalone Android SDK in favor of the Google Play services library. The deprecation allows us to focus our development efforts on Google Play services and offer additional exciting features going forward. Here is the deprecation timeline:

• On August 1, 2014, the Play Store will stop accepting new or updated apps that use the standalone Google AdMob SDK. The standalone SDK does not use the Advertising ID, and will therefore be non-compliant with the Google Play Ad Policy on this date.
• We will stop offering technical support for questions specifically related to the standalone Android SDK on August 1, 2014.
• Ad serving through the standalone SDK will continue to work after August 1, 2014.

There are currently no plans to stop serving ads through the standalone SDK, but we strongly encourage you to update your apps sooner rather than later to avoid the August 1, 2014 deadline. Note that the Google Play services library still supports the same devices -- you can still serve ads through this library even on devices that don’t have the Google Play store installed.

Be sure to refer to our migration guide to help you upgrade. If you have any questions about the deprecation or how to upgrade, post them on our forum. You can also stay tuned to ads-related SDK updates on the Google Ads Developers +Page.

 - Eric Leichtenschlag, Mobile Ads Developer Relations

On February 18, 2014, we will stop providing forum support or bug fixes for iOS IMA SDK issues specifically related to iOS 5. This applies to the current beta of the iOS IMA SDK as well as all future releases.

What does this mean if an app is currently targeting iOS 5?

• There will be no specific SDK change on February 18th that will break compatibility, so the iOS IMA SDK should continue to work with iOS 5 in the short term. However, after that date, the SDK won't be guaranteed to work for iOS 5 apps. 
• Bugs that only affect iOS 5 will no longer be prioritized. 
• If a specific iOS IMA SDK release significantly breaks functionality in iOS 5, it will be documented in the release notes. 
• This support change will not require you to make any changes to your app specific to the iOS IMA SDK, but you may have to make some changes to your app to set its Deployment Target to iOS 6+. 

What about other iOS versions?

We periodically stop supporting older iOS versions when adoption levels fall below a small threshold. Any time we are preparing to end support for a major iOS release, we will make an early announcement on our blog and release notes page.

If you need any help with iOS IMA SDK issues encountered when targeting your application for iOS 6, or about the iOS IMA SDK in general, let us know on the IMA SDK forum or check out the IMA SDK iOS Quick Start Guide. Follow our Google+ page for other announcements and updates.

 - Bret McGowen, IMA SDK Team

When we launched the new DFP a couple of years ago, one of the major changes was a new API and accompanying support infrastructure. The DFP API brought many significant enhancements to DFP and is a core component of our overall offering. However, as our publishers and partners went through the upgrade process, they had to rebuild any DART API integrations from scratch. In addition, due to the rapid development cycle of DFP, we were pushing out new versions very quickly.

While the terms of service for our API call for only a 6-month window to support each version, to limit the impact to our developers, we've continued to support every version of the DFP API released to date -- that’s 12 and counting. While we've had a “soft” deprecation for older versions, we've only removed documentation - those versions have continued to run.

By the end of this year, all upgrades will be complete and the release schedule for the API will continue on a regular quarterly basis. Given the growing use of our API -- not to mention the growing number of versions we’re supporting -- we’ll need to begin hard deprecations for older versions. As a result, we’re introducing a new deprecation schedule and want to give all our developers enough time to plan for upgrades.

Going forward we are planning to deprecate each version one year after its release. This means at any time we’ll be supporting four versions. For example, when the Q1 release (v201402) comes out, we’ll deprecate support for the Q2 release of the previous year (v201302). That depreciation will be a “soft” one and it will still run until the Q2 release before being completely turned off; i.e. every version will be accessible for approximately 14 months.

In order to help developers adjust, we’ll be phasing in this new schedule. Our next scheduled release will be in Q1. On April 1st, 2014, we will be turning off v201206 and older, and putting v201302 and lower into “soft” deprecation. On August 1st, we’ll be turning off v201302 and older, and v201308 and v201306 will go into “soft” deprecation.

As of April 1st, 2014, these will be the only versions supported on DFP:

Version	State
v201402	Scheduled
v201311	Supported
v201308	Supported
v201306	Supported
v201302	Soft deprecated
v201211	Soft deprecated
v201208	Soft deprecated
v201206	Deprecated
v201204	Deprecated
v201203	Deprecated
v201201	Deprecated
v201111	Deprecated
v201108	Deprecated

As of August 1st, 2014, these will be the only versions supported on DFP:

Version	State
v201408	Supported
v201405	Supported
v201402	Supported
v201311	Supported
v201308	Soft deprecated
v201306	Soft deprecated
v201302	Deprecated
v201211	Deprecated
v201208	Deprecated

And finally, as of approximately a year from now, these will be the only supported versions:

Version	State
v201411	Supported
v201408	Supported
v201405	Supported
v201402	Supported
v201311	Soft deprecated
v201308	Deprecated
v201306	Deprecated

If you are using any version less than v201308 right now, you need to upgrade by August 1st, 2014 and if you are using any version less than v201211 right now, you should plan to upgrade in Q1 2014.

Our recommendation is to upgrade to v201311 now. This will delay your need to upgrade until Q1 2015.

Finally, just a reminder that v201311 is the last version to support ClientLogin and OAuth 1.0 authentication mechanisms. All future versions only support OAuth2. It’s also the last version supported by the old Java client library which means there’s no support for new API releases next year. When v201311 is deprecated in Q4 of 2014, everyone will need to be on a newer version using OAuth2 and the new Java client library.

If you have any questions, please let us know on our Ads Developer Google+ page.

-- The DFP API Team

We are happy to announce the latest SDK release, v6.3.0, for both Android and iOS. v6.3.0 is a bug-fix release that includes:

• Improved logging messages on Android
• Fix for crash in Eclipse when defining an AdView in the graphical XML layout editor
• New logging statement that provides the ID to pass to request.testDevices on iOS to enable test ads on a specific device
• Support for test ads on iOS6
• Fix for crash in GADMraidInterceptor on iOS

Check out the release notes for a full list of updates. Let us know on the forum if you have any questions about the new release. You can also follow us on our Google+ page for ads-related updates.

Deprecation of Old AdMob SDKs

With the release of v6.3.0, we are deprecating old versions of the AdMob SDK to help us better support newer versions. Starting March 18, 2013, we will no longer support ad requests made through AdMob SDKs released before 2011. Requests that come from apps using deprecated versions of the SDK will no longer receive ads.

Which versions of the SDK are you deprecating?

We are deprecating all SDKs which were released before 2011. On Android, this includes any SDK released on November 9, 2010 or before. On iOS, this includes any SDK released on September 8, 2010 or before. See below for information on how to determine if your SDK version is being deprecated.

How do I determine if my SDK version is being deprecated?

For Android, if your code references com.admob.android.ads.* then you are using one of the SDKs that needs to be updated.

For iOS, if you have headers such as AdMobView.h or AdMobDelegateProtocol.h in your application, then you are using one of the SDKs that needs to be updated.

I’ve upgraded my app to use a recent version of the SDK. What will happen to traffic coming from older versions of the SDK starting on March 18?

We recommend you encourage your users to upgrade to the latest version of your app. Traffic from older versions of the app still using the legacy SDKs will no longer receive ads.

Are there any additional benefits to upgrading?

The more recent SDK versions provide performance enhancements, access to our latest ad units, and fixes for common issues.

 - Eric Leichtenschlag, AdMob Team

We’re happy to announce the release of v4.1 of the AdSense Host API. Don’t let the numbering fool you, this is a major update that provides a ton of new functionality!

The new version is intended as a full replacement of AdSense Host API v3 for ContentAds hosts, with a few extra features. Changes from v4 include added support for:

• Account creation and association with a new publisher signup flow
• Managing URL and custom channels on the host
• Retrieving publisher ad clients
• Creating and managing new publisher ad units, and retrieving ad code for them
• Running publisher-side reports

With this new release, we're also announcing the sunset of version 3 of the Host API, to take place on January 1, 2013. Over the next few weeks, we will be getting in touch with existing hosts and helping them get started with the migration.

If you’re not an AdSense host yet and are interested in joining the program, take a look at our introduction page to find out more about the requirements and how it works.

Let us know if you have any questions!

 - Sérgio Gomes, on behalf of the AdSense API Team

Today, we are announcing the deprecation of versions v201108, v201111, and v201201 of the DFP API. In roughly 3 months, on Dec 10th, these versions will be turned off. Turning off older versions allows us to make sure that everyone can benefit from the improvements in more recent releases and to focus on releasing new features.

Although we are not announcing the deprecation of any other versions at this time, we would still like to give our developers using v201203, v201204, and v201206 notice that those versions will most likely be deprecated next. Upgrading to v201208 now will reduce any future development time needed for an upgrade later.

As mentioned in previous deprecation announcements, we will always give at least 3 months notice before turning off a version. Our release notes page also contains changelogs for each version, which will help you migrate to a newer version. If you aren’t using one of our client libraries, now would be a great time to start as well. If you have any feedback or comments about this deprecation, or the API in general, please feel free to leave them on our forum.

 - Adam Rogal, DFP API Team

Today, we are announcing the deprecation of versions v201103, v201104, and v201107 of the DFP API. In 3 months, on May 11th, these versions will be turned off. We are turning off older versions to make sure that everyone can benefit from the improvements in more recent releases and so that we can focus on releasing new features.

As mentioned in previous deprecation announcements, we will always give at least 3 months notice before turning off a version. Our release notes page also contains changelogs for each version, which will help you migrate to a newer version. If you aren’t using one of our client libraries, now would be a great time to start as well. If you have any feedback or comments about this deprecation, or the API in general, please feel free to leave them on our forum or join us in a future hangout on Feb 28th.

 - Adam Rogal, DFP API Team