(Translated by https://www.hiragana.jp/)
Google Ads Developer Blog: announcement

Beginning in June 2020, we rolled out stricter validation of long and integer request fields in the Doubleclick Bid Manager (DBM) API. This rollout finished in early August and now applies to all traffic.
Beginning in June 2020, we rolled out stricter validation of long and integer request fields in the Doubleclick Bid Manager (DBM) API. This rollout finished in early August and now applies to all traffic.

This new request validation no longer allows the use of decimals in string values submitted for long and integer field types. Previously, an integer field in a request body would accept, for example, “123.0” as a permissible value. Now, identical requests will return an HTTP 400 error with status INVALID_ARGUMENT.

Before the implementation of this validation, the API truncated invalid values at the decimal point and the digits after it were ignored. You can replicate this previous behavior by truncating values at the decimal place before making a request.

Verify that your code converts values with decimals to longs and integers. If you receive an INVALID_ARGUMENT error, make sure your numbers are actual longs or integers.

If you need help adjusting for this new validation or want to report a separate issue, please contact us using our support contact form.

Update (Sep 1, 2020): Support for path and path attribution report types is now available in v3.4. It has been added back to this post.

Update (Aug 7, 2020): Support for path and path attribution report types, originally listed in this blog post, was not included in the initial release of v3.4 of the DCM/DFA Reporting and Trafficking API. It has been removed from this post.

Today we're releasing v3.4 of the DCM/DFA Reporting and Trafficking API. Highlights of this release include:

Details of these and other changes are covered in our release notes.

Deprecation and sunset reminder

In accordance with our deprecation schedule, this release marks the beginning of the deprecation period for v3.3, which will sunset on February 28, 2021. After this date, any requests made against v3.3 will begin returning errors.

Learn More

As with every new version of the DCM/DFA Reporting and Trafficking API, we encourage you to carefully review all changes in the release notes. For those of you looking to get going right away, updated client libraries are now available. If you're just starting out, the Get Started guide is a great reference to help you get up and running quickly.


Give it a try and let us know if you have any questions!

On July 14th, 2020, we will begin enforcing stricter validation for requests to the DCM/DFA Reporting and Trafficking API. This change will initially be introduced for 5% of API traffic during the week of July 14, 10% the week of July 21, 30% the week of July 28, and all requests by August 7th, 2020
As a result, your requests might begin returning additional errors. Please update your requests, as needed. 

The following list includes the error codes that you might see, as well as the recommended solutions:
  • "Invalid value - Enum" - Ensure you are using valid enum values. For more information, see the API Reference.
  • "Invalid value - Bool" - Ensure boolean fields in the request are set to true/false, rather than empty string.
  • "Invalid value - Integer ####.0" - Ensure integer fields in the request are set to valid integers.
  • "Invalid JSON Payload - NaN" - Ensure NaN does not appear in the request payload.
  • "Invalid JSON payload received. - not repeating" - Do not use arrays for non-array fields.
Method specific errors:
  • dfareporting.reports.run: "Invalid JSON payload received. Unexpected end of string. Expected a value" - Ensure the request body is completely empty.
  • dfareporting.reports.list: "Request contains an invalid argument." - Ensure that empty fields in the response contain a valid value. For example, empty array fields must be specified by an empty array, rather than an empty string or object.
  • dfareporting.files.get and dfareporting.reports.files.get: "OAuth token was passed in the query parameter. Please send it in Authorization header instead." - Requests must use the HTTP header Authorization: Bearer [ACCESS_TOKEN] to pass OAuth credentials.

Why is this changing?
Stricter validation helps ensure that problematic requests are not silently ignored, and aligns the behavior of the DCM API with that of other Google APIs.