Testing is an important step in building a successful Google Ads API integration, whether you're just getting started, currently maintaining an app, or adding new features to an existing integration. This guide presents some best practices for testing your Google Ads API integration.
Test accounts
Test accounts are available for development purposes. While not all features can be tested in a test account, it's still a useful tool for validating that your application code and configuration are working as intended.
Production accounts for development
When test account limitations prevent you from testing some features in your integration, you can instead use a production account for development. Production accounts for development differ from test accounts in the following ways:
- Serve ads that can be seen by users
- Require valid URLs
- Must comply with advertising policies
Because production accounts serve ads, they generate metrics letting you test performance reports, as well as unlocking all the other features of the Google Ads API.
At the same time, using them for development requires extra caution. We recommend taking the following measures:
- Only grant access to users that need it for development purposes.
- Set a fixed, low daily account budget.
- Use production accounts for development only when test accounts can't be used.
Test credentials
To minimize the risk of accidentally modifying production accounts when trying to modify development accounts, we recommend maintaining a set of test credentials that are separate from your production application credentials.
We also recommend creating separate refresh tokens for development purposes.
A refresh token is generated when a user authorizes an app to access the Google Ads API on their behalf, so each refresh token has the same access as the authorizing user. If all of the refresh tokens used to access development accounts are associated with users that don't have access to production accounts—including manager accounts that manage production accounts—then the risk of accidentally using a test refresh token to modify a production account is mitigated.
Because access is dependent on the refresh token that is used, there is no need to create test credentials other than test refresh tokens. The developer token, client ID, and client secret that are used to access production accounts can safely be used to access test accounts, provided the refresh token is distinct.
Request validation
If you just need to test whether a request is valid—for example, to
verify that the request is structured correctly and does not violate
policies—you can use the
validate_only
field, which is available for GoogleAdsService.SearchStream and
GoogleAdsService.Search requests, as well as most mutate requests.
Consult the reference documentation to verify
whether this field is available for a given method.
REST API
For ad hoc testing, for example to validate that a request yields the expected output, using the REST API is often the easiest option. Consult the REST examples to learn how to use cURL in making requests to the REST API.