When we originally launched this blog in 2010, we sought to provide you with the most up-to-date information on the DoubleClick for Publishers (DFP) API, as well as useful resources to help with API development. Recently, we’ve realized that the content we produce can be shared between multiple Ads API developer communities and for this reason we have decided to create one central blog. With this in mind, we'll now be posting on the new Google Ads Developer blog. There, you'll also find information on our AdSense API, AdWords API, DoubleClick for Advertisers API, and Google AdMob SDK products.

If you’re a subscriber of this blog, your feed will automatically be redirected, so you won't have to do a thing to keep getting the latest news. If you decide you'd like to subscribe to a particular label on the new blog (for example, only receive those posts labeled as dfp_api), you can choose to do that as well. Also, the old content of this blog is not going anywhere and will continue to be available, even after we switch to the new blog.

The Ads Developer blog will continue to be run by the same team, bringing you all the information you need as an ads developer. We look forward to seeing you over at http://googleadsdeveloper.blogspot.com/.

Posted by the DFP API Team

In February 2010, we announced the new DFP API and have come a long way since the announcement. We’ve been busy innovating and have released seven versions of the API, including production access to the API in October last year.

Today we’re excited to announce that the DFP API is moving out of beta and is available to all publishers.  As part of this announcement, the DFP API program policies and terms of service have been updated to reflect this change. Additionally, activating your account to use the API can now be enabled by your account administrator.

If you have previously signed up for the DFP API using our production sign-up form, your API access will continue to work but please review and agree to the new terms of service.

We’re excited to take the API out of beta and make it available to all publishers, and we’d like to say a special thank you to the developer community who has provided us with great feedback to help get the API to this point.

DFP API Team

Today, we’re pleased to announce the v201108 release of the DoubleClick for Publishers (DFP) API. In this release, we have included support for video, postal code targeting, custom creatives, creative placeholders and more.

Video Support

The API now supports video environments (including Flash applications) in addition to the traditional browser environment.  We added the environmentType attribute in line item and ad unit size to distinguish whether the line item or ad unit targets a browser or video player. When a line item is set to target video players, it can only target ad units with ad unit sizes that also have the video player environment type. Ad unit sizes set to target video players can have companions, which are a set of ad unit sizes that will display alongside the video player ad.  

Postal Code Targeting

The postal code targeting feature is now available in the DFP API.  As a developer, you can use this feature by creating a Location with an ID and adding that to your geoTargeting object.  The correct ID can be fetched using the PublisherQueryLanguageService on the Postal Codes table. For examples on how to fetch IDs and set targets in the DFP API, please take a look at our previous geographical targeting blog post.

Custom Creatives

Also available as a DFP Premium Solution feature, the CustomCreative type provides a way to represent a creative with an arbitrary HTML snippet along with its associated file assets. The custom creative assets in a custom creative can be images, CSS stylesheets, and JavaScript files that are referenced in the HTML snippet. In this release, creative asset IDs will be shown on creatives that have assets, but they cannot be fetched directly. The ability to create and update assets through the API will come in a future release.

Creative Placeholders in Line Item

Line items now have a creativePlaceholders attribute which replaces the creativeSizes attribute in older versions. The attribute is required and represents a slot that a creative is expected to fill in a line item. A creative placeholder can have companions, but only if the line item’s environment is set to video player.

Ad Unit Sizes

The adUnitSizes attribute replaces the sizes attribute in the AdUnit object. The permissible creative size in an ad unit is now specified in the size attribute of an AdUnitSize object.

These highlights are just some of the features we have in the v201108 release; more details can be found in our release notes.  We value developer feedback, so if there are any features that you would like to see in future releases, please let us know at our forum.

  Jeffrey Sham, DFP API Team

As mentioned in our recent deprecation blog post, we will be sunsetting (turning off) versions v201101, v201010, and v201004. We’ve added an extra week to our sunset date; the versions will now be turned off on August 31st. Our client libraries always have the most recent versions and are a great way to stay ahead of the curve. As always, if you have any questions about our deprecation policy or how to upgrade, please let us know on our forum.

Adam Rogal, DFP API Team

Recently, we have migrated the Google Apps accounts to a new infrastructure that includes all Personal Google accounts.  This has introduced a conflict for API users who have the same email address for both types of accounts.  As a result, you will not be able to generate a ClientLogin token and will be presented with an AuthenticationError.NO_NETWORKS_TO_ACCESS in the SOAP response.  You can also verify whether your account in conflict by making a request directly to the Client Login API.

Request:

https://www.google.com/accounts/ClientLogin?accountType=GOOGLE&Email=my_email_address&Passwd=my_password

Response:

Error=Unknown\nUrl=https://www.google.com/accounts/ErrorMsg?Email=my_email_address&service=gam&id=unknown

Before the migration, it was possible to have a Google Apps account with your domain (jane@altostrat.com) and a Personal Google account for DFP, Picasa, Reader, etc. with the same email address.  With the new infrastructure, both types of accounts are in one unified system so when you try to generate a ClientLogin token with jane@altostrat.com, we do not know which account you are trying to use.  More details about conflicting accounts can be found at the Google Accounts Help Article.

To differentiate between your conflicting accounts, we have created a temporary account (jane%altostrat.com@gtempaccount.com) for you to temporarily hold your data.  You can log into http://www.google.com/accounts with your gtempaccount and use the wizard to resolve your conflicts.  A full walkthrough on the data migration wizard can be found at the Data Migration Getting Started Guide.

As always, please post any questions to the DFP API Forum.

  Jeffrey Sham, DFP API Team

Today, we’re excited to release v201107 of the DoubleClick for Publishers (DFP) API. In this release, you’ll find support for labels, technology (browsing) targeting, and more.

Labels

Labels can help you categorize your advertisers, orders, and line items, prevent line items from competing advertisers from delivering to the same webpage, and can be used to set frequency caps to ad units. These tasks can now be accomplished via the API using COMPETITIVE_EXCLUSION and AD_UNIT_FREQUENCY_CAP respectively.

Labels can be applied to companies, orders, and line items and are inherited. This means that if you apply a label to an advertiser, it will be applied to the advertiser's orders and line items automatically. If you apply a label to an order, it will be applied to the order's line items automatically. The LineItem.effectiveAppliedLabels and Order.effectiveAppliedLabels fields can be used to determine all labels that are both inherited and defined on the object itself, but the appliedLabels field should be used to update objects.

For more information about labels, please refer to the create, apply, and remove labels Help Center article.

Competitive exclusion for small business publishers

For DFP small business publishers, we have exposed functionality similar to competitive exclusion labels. The Company.enableSameAdvertiserCompetitiveExclusion field prevents ads from the same company from competing with each other. In other words, if two orders exist with the same company or there are two line items from the same order that are eligible to serve on the same page, this field will prevent those two ads from competing with each other. The LineItem.disableSameAdvertiserCompetitiveExclusion, on the other hand, will allow all line items with this set to true to compete with each other, regardless of their labels or company settings.

Technology targeting

Technology (browsing) targeting is also included in this release. Technology targeting allows you to target specific information about the user browsing your site including bandwidth, browser, browser language, and operating system details. The new field Targeting.technologyTargeting can be set with a TechnologyTargeting object with fields for each type of targeting.

To add a new target, first fetch the ID from the respective PublisherQueryLanguageService table and create a Technology object with just the ID filled in. When fetching targets from the API, the objects will be subclassed correctly depending on type. For a refresher on how to set targets using IDs in the DFP API, please refer to the geographical targeting blog post.

External IDs

To help developers who need to reconcile DFP system objects with other systems, we’ve added external IDs to the LineItem and Order objects. Before v201107, the externalId field on Order objects represented the PO Number in the UI. We’ve updated this by renaming it to poNumber and exposing a brand new externalOrderId field. As a developer, you will be able to rename all instances in which you reference externalId as a PO number and use the new field for additional reconciliation.

This blog post has only scratched the surface of the features v201107 brings; to learn more, please visit our release notes page. As always, developer feedback is important to us; if there are any features you are dying to see become a part of the API, please let us know at our forum.

Adam Rogal, DFP API Team

Documentation updates

From our developer day meetings and our user forum, we've received feedback from many of you that while a robust documentation library is needed to learn a new API, sample code is also helpful in order to get started. Therefore, in our documentation, you will now find a side bar with relevant code examples to help you easily learn and implement each service.

The side bar will also contain relevant blog posts, videos, and updates to help you stay up to date on the API. You can view an example of the sidebar on the LineItemService reference page.

Ruby client library

We've received numerous requests from many developers on the forum  asking for a Ruby DFP API library. As with all feedback, we took this to heart, and we're excited to announce that you can now download a Ruby library here. To help you get started, please review the quick start guide on our documentation site.

Updates to the sandbox playground

Today, we've also pushed an updated version of the DFP Sandbox Playground. You'll find that the backend has been updated to v201104 and that a new pane for custom targeting has been added. We've also added the ability to view multiple networks per account. You'll see a drop down at the top of page where you can select any network your email address belongs to. You can try this out by signing up for a new account with a different email address, and adding that email address to your existing network. Once you sign in with that new email address, you'll be presented with your old network, and your new network in the drop down. As always, this application is open source so let us know if you would like to contribute.

Future updates

In addition to today's update, over the upcoming weeks we will be releasing a new version of the API which will help bring the API even closer to offering the full functionality of the DFP UI. We're committed to allow you to perform all operations that you can perform in the UI directly from the API.

Your feedback is always welcome, and iff there are features or operations that you feel would make your API experience better, please do not hesitate to let us know on the forum or on Twitter.

Adam Rogal, DFP API Team