It's well known foursquare users are not able to get the mayorship of a venue if checkin comes via mobile website. But is it also necessary to send the geolocation of a user via foursquare API to get mayorship? If yes, how accurate must the geo information be?
Yes, only check-ins that pass the user's actual lat/lng will be eligible for mayorship. The accuracy required depends on the venue, but the lat/lng reported must come from an independent source (i.e. the phone's GPS) and not be derived or set by the user.
Related
Recently google has added multiple user support to the assistant so how would use the API to identify the person by voice?
It depends what you mean by "identify the person".
There is no way for an Action to get the raw audio, so there is no way for it to do voice printing or anything along those lines.
Although each voice has to be reported against a Google User ID, you do not have direct access to that user ID.
What developers do have access to is a UID that is sent along with each request to your fulfillment server. This UID is consistent across requests, although it can be reset by a user (for example, if they reset their Google Home). You can think of this the same way you think of an HTTP cookie - you can track the UID and, if you see it again, have reasonable assurance it is the same user that accessed it last time. This breaks down, however, for the "default" account on Google Home, since anybody who doesn't have an account will map to this user.
Beyond this, you can also use Account Linking to connect a Google Account consistently to an account in your own system. If you have sufficient authentication in place, or are using one from Google or Facebook for example, this can act as an identity.
There isn't an API for developers to identify users by voice.
Scope:
I am starting an application that will need a very rich database of venues within a certain city right on it's start so i thought that scraping foursquare's database would be a great idea, but seems like scraping volumes over 1000 venues is considered forbidden according to it's usage / data retention policy
My Needs:
Basically, what i want to achieve is a way to allow users to search their favorite venues and receive notifications from them, so having all the venues of this city would be perfect for me, allowing me to store the relationship USER XXX FOLLOWS YYY VENUE
Problem:
Since i can't "copy" / "transfer" all the foursquare venues of a given city to my own database, what can i do to actually "store" the data i need for my own use ?
Is there any workaround for this ? (I don't mean ilegal actions, but some clever use of the API instead).
You can force your users to connect with 4sq (with oauth), then retrieve the data you need using oauth tokenwith 4sq api, which does not violate the rules and put any limits to the amount of data.
You can store user's 4sq id and the venue ids they follow in your own db and retrieve the details as needed. Am I missing sth with this flow?
If users link their foursquare account to my site, via oauth2, when I pull a venue from the foursquare API would I be able to test if the current user is the same user who verified the venue (assuming the venue is verified)?
Or... is it possible to use the foursquare API to know who verified a venue?
I'm trying to build a service which venue owners/managers can use to help their business. However, I'll need a way to verify they are the owners/managers of the venue. I believe a very effective way to do this would be to force them to link their foursquare account, and then test if their account was the one that verified the venue.
If that's not possible, what's the standard way this is performed?
Instead of testing if a venue is managed by the current OAuth'd user, would it make more sense to get all of the venues that the current user manages? You can do that through our venues/managed endpoint.
Also in general, your approach of requiring the user to OAuth is correct and pretty standard for these style of apps. Our info on our merchant platform should be able to help you out.
on the documentation page, https://developer.foursquare.com/overview/venues, it says that
The Venues Platform lets developers use foursquare as their location
layer. Applications can search our database and find information
including tips, photos, check-in counts, and here now. Searches can be
done near a point or through a whole city, and they can be restricted
to trending or recommended places. The platform offers all of this
without requiring end user authentication and is available at high
rate limits.
however, when i send request like:
https://api.foursquare.com/v2/venues/4ad7a112f964a520050d21e3/herenow?client_id=myclientid&client_secret=myclientsecret&v=20120119
i got this:
{"meta":{"code":200},"response":{"hereNow":{"count":16,"items":[]}}}
is there anything i need to do, such as register as a venue platform developer, to get the list of people who are here? thanks!
You cannot get the users information without authenticating [ :( ]
Check out the documentation at the herenow endpoint page.
Specifically the first line:
Provides a count of how many people are at a given venue. If the request is user authenticated, also returns a list of the users there, friends-first.
I am imagining a scenario in which a user is checked into a venue by taking action with a particular device.
The most common scenario would be a gym/fitness center where a patron would scan an ID card or badge up entering.
Is it allowable to use the foursquare API to check into a venue as such after a user has granted access via oAuth?
Yep!
There are many apps that check people into foursquare using the API. (Including the official foursquare clients, Gowalla (RIP), venmo, foodspotting, and plenty of others).
Your scenario sounds ideal for check-in integration as you have a good sense of location (in this exact gym), and it's an explicit action on the part of the user that starts the check-in process (using a RFID card on machine X).
Just be sure not to abuse the power, because the user will see these check-ins in their timeline. It would probably be good to have a clear policy on the default privacy settings for them (eg - always private).