How can we call fetchVerificationOptions in Google Business Verification API using Google API PHP SDK?

Question

I am currently using various Google APIs. I have approved access to the Google Business API and successfully made multiple calls to its endpoints using the PHP SDK; even calling some endpoints in the Business Authentication API. However, when I request fetchVerificationOptions with the location defined, I receive a 400 error.

Google\Service\Exception
{
  "error": {
    "code": 400,
    "message": "Request contains an invalid argument.",
    "errors": [
      {
        "message": "Request contains an invalid argument.",
        "domain": "global",
        "reason": "badRequest"
      }
    ],
    "status": "INVALID_ARGUMENT",
    "details": [
      {
        "@type": "type.googleapis.com/google.rpc.BadRequest"
      }
    ]
  }
}

I have verified that the location passed in is correct, in the format "locations/<LOCATION_ID>". I've used the same key in many other successful calls.

I have read multiple times all the documentation I can find on this topic. The error makes me think that the data I'm sending is wrong, but the documentation is very clear about what is expected - the language code and optional context. In my current case the location is a CUSTOMER_LOCATION_ONLY business type and the PostalAddress object needs to be provided in this request via context. The SDK makes this seem easier by providing objects for every piece of the puzzle.

Here is my relevant PHP code:

$options = new FetchVerificationOptionsRequest;
$options->languageCode = 'en-US';

$context = new ServiceBusinessContext;
$context->setAddress($postalAddress);
$options->setContext($context);

$verificationOptions = GoogleBusinessProfileApi::getVerificationService()->locations->fetchVerificationOptions($locationName, $options);

I have verified that $postalAddress in the above code is an instance of Google\Service\MyBusinessVerifications\PostalAddress which contains valid address details.

I've verified that $locationName in the code above has the correct value; my location ID in the format "locations/<LOCATION_ID>".

GoogleBusinessProfileApi::getVerificationService() in the code above returns a Google\Service\MyBusinessVerifications instance that contains my Google client and all the authentication stuff. I use this method for all my interactions and they work perfectly fine. Also, this error does not indicate a problem with the part.

It's also worth noting that on my Google API development console, I can see these requests coming in and ending with a 400 response. However, this is only what the indicator looks like. I can't find any deeper, more detailed information about the request.

I'm looking for anything - direction, ideas, thoughts. Has anyone else dealt with this before? Am I missing something obvious? Is this a problem with my code or the API itself? Does anyone know how to dig deeper into these errors on the Google Console?

Thanks!

Answer 1

solution:

Set the PostalAddress subregion to null.

details:

With the help of colleagues, we figured out what was going on. I changed the code to call the old, deprecated API version. This returns a more helpful error message stating that the United States does not use subzones in its addresses. I set it on the PostalAddress object so I changed it to always be null and the request worked on both the old and new API.

There is a lot to be frustrated about.

1. wrong information. The response from the "new and improved" API should tell me as much information as the old version, if not more.
2. document. I can't find any description anywhere about the US subregion for this particular request.
3. provide help. At the time of writing this article, searching Google for anything on this topic has returned essentially nothing.
4. Sub-area. The way my system is set up is to actually use Google's location lookup to get a valid PostalAddress to make sure the data we're sending them is valid. In this case, we're using the address that was returned to us from Google...with subzones. Sub-localities have county names; something we use in the United States. So there's even less reason to think that's the problem. While I don't agree with the accuracy of the error message, I do need it to understand the problem.

While this doesn't seem to be a big problem on the web right now, I do hope that one day this can help others avoid wasting their time.

~Cheers~