Deprecation of v201101, v201010, and v201004

Monday, May 23, 2011 | 3:00 PM

Labels: , ,

Today, we are announcing the deprecation of versions v201101, v201010, and v201004 of the DFP API. In 3 months, on August 22nd, 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.

We will always give at least 3 months notice before turning off a version. We will also supply information on migrating from deprecated versions on our release notes page . We suggest that if you aren’t using one of our client libraries , now would be a great time to start.  In the client libraries, we provide lots of code examples that you’ll be able to use as a “rosetta stone”, going from one version to the next. Since this may be the first migration for many of you, below are some tips for migrating from v201004.

Bind variables have been renamed to Value

In v201004, bind variables were named Params . In v201101, they were renamed to  Values . To migrate your code, you may have to instantiate the new Value class instead of Param. You will also have to consider that Statement  now takes an array of String_ValueMapEntry .

Authentication changes

Tokens are now wrapped in a complex type. For example, where you would once just put <authToken>, you now include an <authentication> element with the proper xsi-type i.e. xsi-type=”ns1:ClientLogin” (where ns1 is the DFP API namespace). For a full discussion of this change, see the blog post on Announcing v201103 .

New targeting

Several targeting features  have been added since v201004. These include geographical , day-time , user domain , and custom targeting . If you were setting these targeting options for lineitems on the DFP website and not including them in the API, you may have already been messaged that you should update your API version.

Reporting changes

There were a few changes to reporting introduced in v201103. In v201004, ReportQuery  could have a custom startDateTime  and endDateTime . To align the API with the features of the product, the ReportQuery  object now only takes dates for startDate  and endDate . Furthermore, this also fixes an issue where an additional day past the endDateTime was being returned. When migrating, you may be able to remove this custom code that fixed this behavior.

We hope that these tips will help you migrate your code faster and 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