I am working on a social app that needs to let users add new venues to Foursquare in rare occasions. Many if not most of these users may not have a Foursquare account, and I would then like to avoid requiring them to create one just for that feature.
I've read the related thread about Adding Venues without Authentication. Although ideal, this solution is unfortunately not accessible to us since we're a small startup.
So here's my question: could I use a single default FS account, that would be registered to my startup, to add venues on the behalf of all my users? In other words, each a time any user needs to add a venue, the app would be authenticating to FS using the same account in the background.
Would such model be allowed and supported by FS, or considered abusive?
Thanks a ton in advance for any guidance on this.
Since you said adding venues is a rare occasion that should work fine. You'll be rate-limited on that single authenticated account, but it shouldn't be an issue at low volumes. I believe the default limit is 500 requests per hour per authenticated user. If you're adding more than that, you're not a small startup :)
Related
I have some doubts regarding the custom connector we are trying to build for docusign : -
Regarding the license plan that need to be bought by the customers who will be granting access for our connector to collect data from their docusign organization account. I am looking at the link https://www.docusign.com/products-and-pricing. API access support is mentioned in only the advanced solution. So I was wondering whether only we need to have "Advanced solutions plan with APIs support" plan or all our customers need to API access support in order to fetch their data.
As per the documentation, to make the REST API calls we need two fields 'base_uri' and 'account_id' (https://developers.docusign.com/esign-rest-api/guides/authentication/user-info-endpoints). Now, the response of userInfo API call gives an array of accounts and its respective fields. My doubt is, if multiple authenticated users (more than one accounts) are returned in this array but all are part of same organization, will they all have different account_ids. Main concern here is, will there be several Base Paths (https://developers.docusign.com/esign-rest-api/guides/authentication/user-info-endpoints#form-your-base-path) to make API calls?
2a. Further question is, what is the significance of 'is_default' field?
Is this related to main account (if is_default is true) using which we will create our Base Path?
Since this is a tech/engineering forum I'm going to answer only question #2 as question #1 is more of a business/sales question.
The reason you may get multiple accounts is that an authenticated user in DocuSign can be a member of multiple accounts. That said, it's the same user. Meaning, say foobar#blah.com has an account 123 with company X and account 456 with his school, then it's possible that when foobar#blah.com authenticates (With the same password!) to DocuSign we have a list of accounts associated with that user. We give you all of them when you make the API call. The default one is the main one that you would see when you log into our web app. You can decide yourself as the user which one is the default. Users who log into our web-app then see an option at the top-right to change accounts.
and yes, every API call is associated with a specific account. So when you construct the urls for your API - you do need to know which account for this user you are making the API call for. Your application can decide how to handle this.
Hope this helps.
I'm making an app that authenticates a coach with KA's API, in order to present statistics and reports on the progress of each student.
How do I see "For whom am I a coach" (inverse of /api/v1/user.coaches)?
or otherwise request user and progress data for all my students?
You can request /api/v1/user/students to get a list of the currently authenticated users' students. Note that this is an undocumented endpoint, not sure if that's on purpose or not, but I suspect just an oversight because IIRC I've seen them reference it on github issues in the past.
I added that endpoint to the khan npm module in this PR: https://github.com/weo-edu/khan/pull/4
An important caveat to note is that as of this writing, you won't be able to request students on behalf of a user who has authenticated your application, only the user who created the app you're currently using.
Put another way: If I create an application called "hello" while logged in as "Jeffrey", I can get all of Jeffrey's students by authenticating with the "hello" app. However, If I log in as Lisa via the "hello" app (via oauth, e.g. passport-khan), I'll have an access token but the Khan API will refuse my request because Lisa did not create the "hello" app.
This behavior is documented (albeit a bit confusingly) in this wiki page, here's the relevant paragraph:
It is recommended that schools have one teacher/coach account that registers for an API key. This enables a situation where the logged-in user is the same as the third-party developer, who then can access their own students' data pursuant to Khan Academy's "coach" relationship. For example, suppose the principal of Riverdale High wished to export data for multiple students via the API. The principal would create a teacher/coach account, perhaps called "RiverdaleHighAPI," and register for an API key. The principal would then ask all students of Riverdale High to add "RiverdaleHighAPI" as a coach, either directly or via several class codes. When accessing the API with "RiverdaleHighAPI" as the logged in user, the principal would be able to access the data for all students that have added "RiverdaleHighAPI" as a coach. The app would not have access to any other coaches' student data, even if another coach logged in through the app. To protect student privacy, we do not allow indirect consent through the coach, and we require each student to explicitly grant permission to access their data. Please note that we are working to improve this functionality; for the time being, this "RiverdaleHighAPI" account should only be used by the school's API client, not by any actual teacher or coach.
Lastly, khan actually encourages public use of their internal API. They recommend opening up your developer console while logged in to khan and looking for the endpoints that return the data you want. (see this note on their authentication document).
This is obviously a fairly non-standard practice and I assume the endpoints would be subject to breaking changes without warning. Also you'll be flying documentation free. That said, this approach may be the most robust option for your purposes. Here's the quote from their wiki for posterity:
The API explorer documents our public API, which has URLs starting with /api/v1, but unfortunately it's not very well-maintained and lacking in a few areas.
If you're feeling adventurous, though, you're welcome to use any internal undocumented API endpoints. For example, if you load a Khan Academy video page and use your browser's developer tools to look at the ajax requests being sent, you'll see that it gets a URL like /api/internal/videos/aubZU0iWtgI/transcript, which contains a JSON response with the video subtitles. That "internal" in the name means that we don't provide documentation, and we may remove the endpoint or change the format in the future, but you're welcome to use any internal endpoints if you keep those caveats in mind.
Is the baseUrl value returned per user or can it be used by all future users of the same account? I want to cache this value and as far as I can tell this is actually an account setting even though it's only retrieved after a user specific login. Any chance two users of the same account could have a different baseUrl? Just want to know at what level i really need to cache this.
thanks,
-mike
It is Per Account
Is the baseUrl value returned per user or can it be used by all future
users of the same account?
restapi/v{#}/login_information
This call will give you back the list of accounts that the username/password has access to. Along with the list of accounts, you'll receive the baseUrl for that account.
baseUrl defines two things:
The server that the account resides on
The account number
If there is a specific account that you're going to add users to, the baseUrl will be the same for future users of that account.
If you do not have multiple accounts logging into your application.
You can cache the information from this call so you don't have it in every workflow. It is mostly used for setting up new workflows and moving between Demo and Production.
If you do have multiple accounts logging into your application.
I would advise that you call this information at the start of your workflow. It'll ensure that you're calling the correct account for that user.
One thing to keep in mind, that 1 set of username / password can have access to multiple accounts. So you may receive more than 1 array as a response, your application should handle this accordingly.
DocuSign's LoginInformation method enables the implementation to provide dynamic re-direction of the clients at a macro-level.
Currently, or in the future, DocuSign might use the feature for a number of different reasons that I can imagine.
Using an undocumented "feature" (properties of the baseURL result) can result in a brittle client that may fail in the future. Be careful of the siren-song of pre-mature optimization.
The baseURL value changes only when you move from different environments (i.e: DEMO vs PROD). I would encourage you to store/cache it yes. Keep in mind when your application is ready for PROD, you will want to get the baseURL for PROD and store/use that appropriately.
Out of curiosity and because I couldn't find any information on this in the API policies: Does foursquare allow using the venue database to rebuild the check in feature with another social network?
Say someone builds MyCoolSocialNetwork and wants to provide a check in feature that does not require his users to sign up for foursquare user accounts. Would it be OK to build an app where users would check in at venues taken from the foursquare venue database, but using their MyCoolSocialNetwork account? Obviously those MyCoolSocialNetwork check ins would only be visible inside MyCoolSocialNetwork, but not on foursquare (and vice versa). Technically, MyCoolSocialNetwork would have a check in database of its own that would be independent of foursquare's.
Technically this doesn't seem like a violation of the API terms, but I would strongly discourage this for these reasons:
You will need to attribute Foursquare in any search results or link to our venue pages when you're using Foursquare data (which you will be). This creates a strong link between Foursquare and your app & the venues you're using.
It will then be extremely confusing from a UX standpoint if you're offering your users to check in, but these check-ins aren't reflected on Foursquare itself.
I think you're better off authenticating your users through Foursquare and letting them check in on Foursquare itself—all the hard work is already done for you! We also recently released native auth libraries for iOS and Android to make this process easier.
I want to add venues to foursquare from my app but I don't want to make the users sign in into foursquare. I created one fake user that my server uses for all the real users of my application, but I'm afraid foursquare will block this fake user becauase it's going to add many venues, and from different places at the same time.
What's the best solution?
thanks.
Your set up is definitely not recommended, but as a way to mitigate your risks, limit the number of venues a user can create via your app (like 1 per day). Otherwise one abusive user can cause your entire user account to be suspended.