Google-api-php-client: Insert in Verification API with TAG_MANAGER throws 503

Created on 11 Sep 2014  路  2Comments  路  Source: googleapis/google-api-php-client

Attempting to verify a site using the TAG_MANAGER always results in an Exception being thrown due to a 503 response being returned with "(503) An unexpected error occurred. Please try your request again.".

I'm using a google service account for the authentication and the account does have edit access to the tag manager account.

The request looks something like the following

POST https://www.googleapis.com/siteVerification/v1/webResource?verificationMethod=TAG_MANAGER
content-type: application/json; charset=UTF-8
authorization: Bearer scrubbedtheauthorizationinfo
accept-encoding: gzip
content-length: 129
BODY: {"owners":["[email protected]"],"site":{"identifier":"http://49lawstreetcaversham.com","type":"SITE"}}

The response comes back like

HTTP 503
content-type: application/json; charset=UTF-8
content-encoding: gzip
date: Thu, 11 Sep 2014 07:23:10 GMT
expires: Thu, 11 Sep 2014 07:23:10 GMT
cache-control: private, max-age=0
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block
server: GSE
alternate-protocol: 443:quic,p=0.002
transfer-encoding: chunked
BODY: {"error":{"errors":[{"domain":"global","reason":"backendError","message":"An unexpected error occurred. Please try your request again."}],"code":503,"message":"An unexpected error occurred. Please try your request again."}}

If there's something that I'm doing wrong here, it would be great if the response method could indicate what was going on.

triage me

Most helpful comment

Just noting this down in case someone else stumbles in to the same problem. This was eventually resolved this morning; the service account user that is using the API needs to have manage and view access to the Google Tag Manager account, not just the container that is present on the site being verified.

The level of access required is surprisingly high and the HTTP 503 response is very misleading as to the underlying problem.

All 2 comments

As with other issue - this tracker is just for bugs with the client library itself. 503 does look like something is broken with the API itself though.

Just noting this down in case someone else stumbles in to the same problem. This was eventually resolved this morning; the service account user that is using the API needs to have manage and view access to the Google Tag Manager account, not just the container that is present on the site being verified.

The level of access required is surprisingly high and the HTTP 503 response is very misleading as to the underlying problem.

Was this page helpful?
0 / 5 - 0 ratings