We received from google-developer email asking us to "Migrate your Contacts API to People API before June 15, 2021, to ensure error-free API calls; API calls will otherwise return 100% errors by December 15, 2021.".
Contacts Api (https://developers.google.com/contacts/v3) needs the following scope:
https://www.google.com/m8/feeds/
and the support asked to abandon it.
But this is the same https://www.google.com/m8/feeds/contacts/ of the Domain Shared Contact API.
So my question is: can we continue to use Domain Shared Contact API?
thk Federica
Unlike the Contacts API documentation:
Warning: The Shared Contacts API is intended only for external contacts. Using this API to create contact information for domain users or groups can result in duplicate contact information for those users and groups, which may lead to unexpected behavior.
The docs on Domain Shared Contacts don't mention anything about deprecation. THe Domain Shared Contacts API is a part of the Admin SDK which is a completely different API, so I think it's safe to assume this will continue to work without issue.
Related
Here is a quote from https://developers.facebook.com/docs/apps/review/
Beginning April 4, 2018, all apps, including those formerly approved,
must undergo App Review in order to gain access to the Events API,
Groups API, and Pages API. Apps accessing the Events API and Groups
API will lose access and require review once App Review resumes. For
apps using Pages API, review will be required once App Review resumes
or access will be removed.
My app uses a Group API to fetch posts from the several groups and display it more convenient way. Now, to get it back I need to pass a Review which is forcing me to ask what permissions I want to use and show how (make a screencast)
Issues:
I don't need any permissions from the user.
The app is under the developing so I actually need to get an access to the API to create an APP and then show to a reviewer how to use it.
Here is API changes: Going forward, all apps will require explicit admin authorization. How exactly admin suppose to authorize it?
Any clarifications, discussions and tips are welcomed.
When I make requests I do not get frequent contacts, just saved. I understand this technically "is working correctly" but the google Contacts API documentation (which does show frequent contacts) states:
Note: For read-only access to users' contacts, use the People API, which provides both contact and profile information, and does not use the older GData protocol.
Feel like that's telling me People API is a newer version of Contacts that supports the read only version of Contacts, so I'd assume it should exist.
I read that the Admin SDK works for Google Apps resellers, but I'm having one specific problem.
I want to use the following request to get the number of user licenses in use on one of my customer's domains.
https://www.googleapis.com/admin/reports/v1/usage/dates/%s?parameters=accounts:num_users
But there's no way that I can find to specify the customer's domain name that I want to get the usage report for. Tried a few different ways.
There must be a way that is hiding from me because this was possible with the old deprecated API.
Thanks.
Using the Reports API for this is not advisable because it can be delayed by 48+ hours. It's also not possible for reseller users to run reports for customers at this time. Rather, you should use the Google Apps Reseller API to list subscription counts that should be fully up to date.
Looks like this API here will do the trick:
https://developers.google.com/admin-sdk/admin-settings/#retrieving_the_current_number_of_users_in_a_domain
It is very important that Facebook Connect and Facebook app users aren't duplicated in our website. So if they already have an account on our website, when they connect through FB Connect or our Facebook app, we want to link rather than create another account. We typically do so by matching email addresses.
So I was excited to see an FQL field for email_hashes in the user object. However, that doesn't return anything. I think I need to use the connect.registerUsers REST api function to first send facebook all the email hashes for my users. That's fine, but that mechanism is now deprecated.
Is there a way to get email hashes from Facebook users?
The only way still is as you detailed and as is documented on connect.registerUsers. email_hashes will be populated if you first call connect.registerUsers and there is a email match. I wouldn't be too concerned about it being deprecated as I am guessing they won't remove this functionality without first migrating it the the graph api as they say they will do on the documentation page.
I am new to this but I will try my best to explain what I am trying to do.
I have a catalog of products and various private information that my users want to be able to access via their website.
For example:
User-a has an e-commerce site and they want to sell my merchandise. They will be able to access a certain products details via a web service. They will also be able to see the negotiated rate that I've given them along with some other private details.
How should the API handle authenticating the request that comes from User-a's website?
I've been reading all day about different authentication methods but they all seem to revolve around the idea of a third party accessing specific user information. An example is if you let http://randomtwitterapp.com access your twitter profile. In that case, the third party site must manage multiple different users and auth tokens. In our case, my users website is interacting on behalf of the user. I hope this makes sense.
Let's call user A "Alice" because calling her User-A is cumbersome.
Treat Alice's web site as if it were Alice herself. The special pricing and such IS specific to the web site in question, so have it log into your site. Issue credentials that the person developing that site would use to authenticate with, and then use those credentials to determine the pricing and products you show.
As for actual authentication mechanisms, it really depends on your needs. If all you need to do is serve different data to different people, you could do something as simple as an API token passed in the query string: http://api.example.com/products?key=9af4d8381781baccb0f915e554f8798d
Or if Alice already has a username and password for your site, you could have her use those in her API requests with Basic Auth.
If Alice is going to need to enter her account information on various sites that she doesn't control, then oAuth comes in very handy. With that, you can essentially give her an API key for every site she needs to access your API from. And you give her the ability to delete those API keys and deny those sites access.