I am working on an representative look up feature for my work's website. Everything is working fine, but we've noticed that when testing it out, some people's addresses are not returning their city council members.
I've checked out the normalized input field in the API response, and I do not spot anything that would prevent the city council member from being returned.
I tested out some addresses in the documentation here and noticed the issue there as well.
Has anyone else come across this issue with their local elected officials? I am wondering if I need to resort to using the Google Places Autocomplete API in order to submit an address consistent with what the civic info API is looking for.
Not sure what code I'd show to help solve the issue, but here is the request URL:
https://www.googleapis.com/civicinfo/v2/representatives?key=${civicAPIKey}&address=${this.activeAddress}
Related
We are using People API to fetch details from Directory . The API is not returning the name for most of the people in the directory. 2 accounts in our GSuite account alone provide the name field, while the others don't. However, other details like emailAddresses and phoneNumbers are available for everyone.
We didn't find any finer grained control for individual fields when using the setting External Directory Sharing → Domain and public data
We tried to change the setting from default to External Directory Sharing → Public data and authenticated user basic profile fields. However, this results in API response showing PERMISSION_DENIED error.
For one of the users in directory, we created Google Currents account. When the account was created and active, the name field became available for this user. After the account was deleted/deactivated, the name field was no longer available.
People API being used:
GET https://people.googleapis.com/v1/people:searchDirectoryPeople?query=a&sources=DIRECTORY_SOURCE_TYPE_DOMAIN_CONTACT&sources=DIRECTORY_SOURCE_TYPE_DOMAIN_PROFILE&readMask=emailAddresses,names,phoneNumbers,photos
The docs we have referred to so far are as follows:
People API - Search Directory:
https://developers.google.com/people/api/rest/v1/people/searchDirectoryPeople
Let third-party apps access Directory data:
https://support.google.com/a/answer/6343701
A merged view of people information:
https://developers.google.com/people/#a_merged_view_of_people_information
Edit:
cURL command:
curl --location --request GET 'https://people.googleapis.com/v1/people:searchDirectoryPeople?query=s&sources=DIRECTORY_SOURCE_TYPE_DOMAIN_CONTACT&sources=DIRECTORY_SOURCE_TYPE_DOMAIN_PROFILE&readMask=emailAddresses,names,phoneNumbers,photos' \
--header 'Authorization: Bearer <access-token>'
This is a known bug with the People API.
You can find it here in Google's issue tracker: https://issuetracker.google.com/issues/196235775?pli=1. If this bug is impacting you, I highly suggest you leave a comment letting the team know you're currently facing the issue and leave a +1 by clicking the "+1" button on the top right.
In the comment section of this question, it was suggested that this behavior is to be expected and is related to privacy. It's safe to say that's not the case as 1. the issue was accepted as a bug by the Google team, and 2. all other information is successfully returned from the API aside from this field.
Additional information on the resolution
Back in August of 2022, the Google team explained the fix was being held up by a bigger effort:
Hello there - apologize for the delay, we did identify the root cause,
however the fix is blocked on another bigger effort. We recently
started making progress on the blocking issue, and will provide an ETA
as soon as we figure out some of the unknowns for the solution.
However, recently (January 17th, 2023), the bug was assigned to someone at Google. This may suggest that the bigger effort was completed and that the team is now unblocked.
Potential workaround
Hopefully the bug is fixed soon. But in case we're waiting for a while, these workarounds may help.
Email is reliably returned for all directory users. The OP doesn't mention the exact context in which he or she is using the API, but for some applications you might be able to get away with using email (e.g. if you're just trying to identify the Directory user to the end user).
Additionally, if user email addresses in your directory follow a uniform formatting, you should be able to parse those to get the name. This is the workaround I'm currently using. E.g.
john.smith#example.com -> John Smith
jsmith#example.com -> J. Smith
jsmith3#example.com -> J. Smith (if you're at a large organization, you may have to remove some numbers)
Meta Sidenote
Yes, it's valid to post that something is a known bug as an answer. Check out this link if you have questions: https://meta.stackoverflow.com/a/369622/1101602.
Since this morning the Places API has returned NOT_FOUND results for every single place ID we've tried searching for.
We regularly query the API to check details & it has been running fine for over a year but today it's fell over and only returns NOT_FOUND, for over 300 different place ids.
Is there a current issue with the API?
I contacted Google Cloud support today about this because it still hasn't changed.
Yes they no longer support Service area businesses in the Places API. Here is their response:
Thank you for contacting Maps Platform Technical Support. My name is Ana and I'm here to assist you.
Places API mission is to enable developers to help users find relevant places to visit. Since Service Area Businesses are not places users can visit, they do not belong in the Places API. That is the reason why you cannot search it in Places API and it is an intended behavior.
Business owners can fix this via MyBusiness IF they have a brick-and-mortar shop
(a shop someone can visit on the streets).
I find this shocking that developers are unable to pull out information about any ACTIVE business on Google. I have responded with my own views but as expected Google will not change their stance.
Well that is very confusing to customers. You (rightly so) allow local listings to be setup as service area businesses. Why should only brick and mortar shops be allowed to utilise the Place API? That’s separating the market for businesses to advertise properly and surely is not legal.
Regardless of if you agree about service area businesses not being allowed to be shown on Maps – there is no reason that an ACTIVE business should not return details through a Development API which has no public facing impact. It is stifling the support agencies and businesses can provide to its customers.
We're denied access to the Google My Business API and then resort to pulling out data via the Places API and now we can no longer do that.
You should at the very least provide some kind of development data for ANY business that is available on Google, whether that be via the Places API or not – business owners should have a right to pull out data about their own business at any time.
Please forward this to the GMB team.
I've been sending a ton of data to the Google Fit API for a workout being performed by the user, but none of the data is showing up in the app anywhere and I'm not sure how to tell what is wrong. The data is accepted by the API, but none of it is showing up in the user's profile in the app. Does anyone have a strategy for telling if all the different data sets are being connected correctly?
I've been trying for over a year to find someone who works with the Google Fit team to help answer some questions, but I have not been able to find anyone. It seems like the app only wants to show steps, so all the actual workout data that I'm sending it might just be ignored?
How? Easiest method?
Tried using postman on desktop, googles OAuth2 playground and google help pages to try make sense of what to do. Ended up using GAM as this is the easiest and gives the most helpful responses.
I have tried changing this from multiple places and i always get the error:
ERROR: 400: #UserInIllegalDomain Invitation cannot be created for user in this domain - failedPrecondition
the command:
gam update course 8077159861 owner hiddenusername#longleypark.ac.uk
(username is DEFINITELY correct ive just hidden it as its not vital information)
Any help would be much appreciated, from what i can tell some guides said to add longleypark.ac.uk to whitelisted domain under classroom but because this is the primary domain for this g suite it says you cant add your current domain so this isnt an option.
I believe the google API is broken. If anyone can prove otherwise would be a great help.
Google API support haven't managed to give me any proper response, keep saying they will test and let me know but I haven't been informed of any results yet.
Google forums support has informed me once a user account is deleted and 20 days have passed the account becomes unrecoverable which means any classrooms they are the owner of become "orphans" which means "limited functionality" and the inability to change the owner ever again, the only solution is to recreate the classroom from scratch, unfortunately along with the original account all the documents submitted to that classroom are also lost.
There are NO ways around this even though the ownerId field for a classroom really should be editable from some sort of database management tool or admin console/API.
I have run into this problem today. Thought using the API I'd be able to swap the ownerId, but no.
Bizarre that Google don't let you do this as a Google Workspace admin. We know have 3 GCSE sets which are unusable with 3 months of the 2 year course left. Very frustrating.
This issue seems to have started today (2016-08-10) and is still ongoing as of this post. As of yesterday, the places api was returning correct results.
There seem to be 2 locations that are being inserted into api requests for all coordinate requests, these are:
Hôtel de Ville (Paris) (48.856924,2.3526841)
University of Illinois at Chicago Hospita (Chicago) (41.8696656,-87.6704474)
These places are added to all requests, no matter what coordinates or radius are provided.
Anyone else experiencing this, or is it some setting that I have enabled that is including these places by default?
This is the API in use
https://developers.google.com/places/web-service/search
This looks like a bug, the same results came back from a request near the origin: https://maps.googleapis.com/maps/api/place/nearbysearch/json?location=-0.75,-0.75&radius=100&key=YOUR_API_KEY
Please file a bug in the Google Maps API issue tracker:
https://code.google.com/p/gmaps-api-issues/issues/entry?template=Places%20API%20-%20Bug