Third parties are not direct users of DFP, in that they may not have their own DFP network. Instead, they create services or integrations with DFP for their clients, who are DFP customers. This guide covers the basics of third party integrations by providing best practices, tips, and tricks.
This guide assumes you have a working knowledge of the DFP API. If you're unfamiliar with the DFP API, please see our getting started documentation.
Getting started as a third party
To use the DFP API to access a DFP customer's network just follow the guidelines below. No additional approval from Google is required, though note that by using the DFP API you agree to the DFP API terms and conditions, also accessible from the DFP Developers Site.
How to test your DFP integration as a third party
As a third party, you may be wondering how to test your DFP integration before running against your clients' production networks. The recommended approach is to create a test network. You don't need to be a DFP customer to do this. Anybody with a Google account can create a test network.
Note, however, the differences between test and production networks. Test networks cannot serve ads. Test networks will also not necessarily contain all the features that your clients may have available on their production networks. If you need to test against DFP features that are not available on your test network, one option is to purchase access to a non-test network through a DFP reseller.
In addition, you should be clear with your clients about what features they need to have available on their production network in order for your application to work properly. Your application should handle cases where features may not exist by either catching exceptions and failing gracefully or keeping a list of your clients and what features each one has or doesn't have. It should be your client's responsibility to work with their contact at Google to manage features on their network.
Authentication: How to properly access a client's DFP network
In order for your application to access your client's DFP network, you need to set up your authentication workflow in a secure manner.
This involves two main steps.
- Create a Google account email address that you will use to access your client's network.
- Have the client add this account as a user to their DFP network.
For step 1, you may create either a separate Google account for each client, or a master one that you will use for all clients. The former option is more secure in the case that one of your accounts is compromised. The latter means you only need to do step 1 once.
No matter what you do for step 1, in step 2 you'll need to ask each new client to add the appropriate Google account you created for them as a user to their DFP network.
1. Creating a Google account
There are various ways to create a Google account that can be added to a DFP network.
- Option 1 - create an OAuth2 service account, which generates a service account email address for you that acts as a Google account. To do this, follow only step 1 of the instructions here.
- Option 2 - you can create a regular Google account (a.k.a., “Gmail” account) by signing up as a new user. If you already have a Google account, complete this signup in an incognito window, or new browser session. Or, if your company uses G Suite, you can create a Google account in your company's domain and use that instead. For the purposes of this guide, we will refer to both of these as a “regular” Google account.
2. Ask the client to add your Google account to their network
After you've obtained a Google account to access your client's network, ask them to add the account as a new user in their DFP network.
- If you are providing them with an OAuth2 service account email address, have them follow only step 3 here.
- If you are providing them with a regular Google account, have them follow the steps outlined here to add your account as a user to their network.
No matter which route you take, ensure that you discuss with your client what roles and permissions your account should have so that your application can access the data it needs on your client's network.
Now you can start making API calls to your client's DFP network. Make sure you set the networkCode SOAP header to the client's network code you are making the API call against. All of our client libraries allow setting this programmatically. For example, in the ads Java client library, you can programmatically set the network code when building a DfpSession instance.
Keeping up to date with the API
It's important that you stay up to date on which API versions are deprecated or sunset and when new versions are released. You don't want to be caught off guard when a version is sunset and risk breaking your clients. We are not always able to reach out to third parties about impending deprecations and sunsets as we do for our customers. Thus, it is your responsibility to subscribe to one of our three main channels for API updates and adjust your notification settings:
- Our DFP API Sunsets Announcements Group.
- Our Ads Developer Blog.
- Our Google Ads Developers Plus Page.
We also provide a deprecation schedule on our developer's site that you should monitor regularly.
If you run into issues with your DFP integration, we offer the following support channels depending on your issue. If you have a product-level question, please write to the DFP product forums. If you have an API specific question, please write to the DFP API forums. Please see this blog post for tips on distinguishing whether something is a product-level question or an API specific question.