How do we call fetchVerificationOptions in the Google Business Verification API with the Google API PHP SDK?

Question

I am currently working with various Google APIs. I already have approved access to the Google Business API and am successfully making several calls to its endpoints with the PHP SDK; even calls to some of the endpoints in the Business Verification API. However, when I make a request to fetchVerificationOptions of a defined location, I get 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 the location being passed in is correct and in the format of "locations/<LOCATION_ID>". I am using this same key in many other successful calls.

I've read all the documentation I can find on this subject many many times. The error makes me think the data I am sending in is wrong, but the documentation is pretty clear on what is expected - a language code and, optionally, a context. In my current case, the location is a CUSTOMER_LOCATION_ONLY type of business and requires a PostalAddress object be provided in this request via the context. The SDK makes this seem even easier with objects for each 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 code above is an instance of Google\Service\MyBusinessVerifications\PostalAddress holding valid address details.

I have verified that $locationName in the code above holds the correct value; my location ID in the format of "locations/<LOCATION_ID>".

GoogleBusinessProfileApi::getVerificationService() in the code above returns an instance of Google\Service\MyBusinessVerifications with my Google Client and all the authentication stuff taken care of. I use this method for all of my interactions and they work perfectly normal. Plus, the error doesn't indicate there is an issue with this part.

It is also worth noting that on my Google API Dev Console, I can see these requests coming in and ending with a 400 response. Though, that is as far as the metrics seem to go. I cannot find any deeper, more detailed information about the requests.

I am looking for anything - direction, ideas, thoughts. Anyone else deal with this before? Am I missing something obvious? Is this an issue with my code or the API itself? Anyone know how I can dig deeper on the Google console for these errors?

Thanks!

Answer 1

The Solution:

Set PostalAddress sublocality to null.

The Details:

With the help of a colleague, we figured out what was going on. I changed the code to call the older, deprecated version of the API. This returned a much more useful error message stating that the US doesn't use sublocalities in their addresses. I was setting that on my PostalAddress object, so I changed it to always be null and the request worked - on both the old and new API.

There were a lot of frustrating points around this problem.

1. Error messages. The response from the "new and improved" API should be telling me as much if not more than the older version.
2. Documentation. No where that I could find stated anything about the sublocalities in the US for this particular request.
3. Help Available. At the time of writing any of this, googling anything about this topic returned essentially nothing.
4. Sublocalities. The way my system is set up is we actually use Google's Place Lookup to get a valid PostalAddress to ensure the data we send them is valid. In this case, the address we used was returned to us from Google... with a sublocality. The sublocality held the county name; something we do use in the US. So there was even less of a reason to think that would have been the problem. While I disagree with the accuracy of the error message, I really needed that to understand what the issue was.

While this doesn't seem to be a big issue on the web right now, I do hope that this can help someone else avoid some wasted time someday.

~Cheers~