It’s common to have multiple applications access your DFP network(s) when integrating with DFP. How you keep track of these applications and their authentication credentials can be just as important as writing code, particularly if you work with many other developers, or on more than one application. You want to avoid scenarios where you don’t know who or what is accessing your network, or where you can’t determine who owns the Google API Console project from which a set of OAuth2 credentials were generated. Here are some best practices to help mitigate this.
Managing your DFP credentialsIt’s important to ensure that the right members of your team have access to the Google API Console project that generates your OAuth2 credentials. You can easily add multiple collaborators to an API Console project. This will help you track who’s integrating with DFP in a central location, rather than having each developer create their own API Console project.
Similarly, when choosing a Google account for DFP API authentication, you may want to consider an OAuth2 service account. That way, all members of an API Console project can easily access this account’s credentials through the console. This is much better than using an arbitrary individual’s account for authentication in case that person leaves your team, or has their account disabled.
Choose a strong application nameDefining an application name is required when making calls to the DFP API. However, we’ve seen a lot of not so useful application names, such as:
- My DFP integration
- Hello world!
This is particularly troublesome during sunsets when we send out emails identifying which application names are making calls to your network(s) using a deprecated API version. It’s difficult to track down what an application is doing, or who owns it, when it’s named something like "abcxyz". Here are some examples of better application names:
- Monthly report download job
- Weekly forecast script
- Line item viewer