I am working on a project in which i have created an app on flickr. my account is free account. using that app. many users connects to my application and i store their access_token in my database. using that token. my application send requests to flickr and download users public and private data in a server storage. from where the connected users can view only their own backed up data.
I want to know. is there any limitation for free account to download users data. my app downloaded 6000 photos of a user accurately.
please tell me what type of account i needed for my app.
When you apply for a Flickr API license the following explanation is given on the Flickr site as to which license to choose:
First, we need to know whether or not your app is commercial.
Choose Non-Commercial if:
Your app doesn't make money.
Your app makes money, but you're a family-run, small, or independent business.
You're developing a product which is not currently commercial, but might be in the future.
You're building a personal website or blog where you are only using your own images.
Choose Commercial if:
You or your agency works for a major brand.
AND one of the following:
You want to make a profit.
You charge a fee for your product or services.
You will bring Flickr content into your product and intend to sell those services.
Net, if the business behind the app is 'small' or 'independent' you can earn money with a Flickr app and a non-commercial license. If not, you need the commercial license. Flickr retains the right to decide which license is appropriate for your app at any point in time.
Since the text appears inside the logged in area I can't link to it. I've included a screen shot instead:
Since the title of your question is "flickr API commerical application", the limit is 0 for a free API key. You should apply for a commercial API key. You will then be able to negotiate exactly what limits you require - in fact, your costs will be dependent on those limits.
Using the free API for a commercial application is against Flickr's terms of service and may lead to your access being suspended.
The Flickr Terms of Service are listed here:
http://www.flickr.com/services/api/tos/
This is what it says about commercial use:
If the primary purpose of your application is to derive revenue, it is considered a commercial application. Flickr reserves the right to make these evaluations at the time that you apply for the license. Flickr may also monitor your site or application over time to ensure continued compliance with the appropriate type of API key.
If you're in doubt about whether your application is commercial, here are a few common examples of commercial use that may provide you some guidance:
Users are charged a fee for your product or service which includes some sort of integration using the Flickr APIs.
You sell services to Flickr users and use the APIs to bring users' Flickr content into your service.
Your site is a "destination" site that uses Flickr photos to drive traffic and generate ad revenue.
Related
I am a beginner web designer and I am struggling to find relevant information online as to how I should go about managing my API keys for clients! I would really appreciate any tips or insights on how I should go about this!
I hold my own google account and already have my own API key (Javascript API) for my own website. Although, when creating websites for clients, is it okay to use the same API Key? Or should i create a new API Key for each client in my own account (creating new "projects")? Or should i be creating a google account for each client and then creating each client an API Key through their own account?
I also know that there are usage limits on API Keys so I want to ensure I dont exceed these if using one API for multiple sites. How can I monitor this?
Looking for any advice on the best and most efficient way to go about this. I do not know too much on how API Keys work!
Much appreciated :)
I will be using Google API as an example. Yes, you should always Create a new project for each client there are a multitude of reasons why you should do this and you already mentioned some of this
API query usage limit.
Separated client billing & usage breakdown for each project.
Security and revocation of compromised APIs.
Restricted security profiles, domain whitelisting, IP address, device usage etc..
Access management and role management.
Traffic and analytical reasons.
Creating credentials
Depending on your organisation needs and project scale, for us, we Create credentials (API key/ OAuth ID/ Service Account Key) for every platform the key will be used. For example, if we are developing an e-commerce website that comes with an app, we would issue 3 keys. (1 for web, 1 for Android apk, 1 for iOS app). This allows us to fine tune the access permissions and let us track usage.
What works for you?
If you are a freelancer or work in a small enterprise, the least you should do is separate every client by projects. There is no need to create a new Google account for each project. (You can always transfer ownership of projects to another account if your client requests at a later time)
The above screenshot is how we categorize items in our account, for each project we are contracted for (could be the same client) we will create a separate project entry.
I'm struggeling with the Instagram Permssion Request. We need to use the API to scan for new uploads to Instagram with a specific hashtag, to trigger a machine.
For this, i tried to request the permission for "basic" and "public content". The request was declined for several times, primarily because the screencast does not contain any Instagram login process in our app. Since there is no need to login for our purpose, i dont know how to realize this. We also dont want to use any 3rd party tool, but just the Instragram API. Do you have any advice for this?
Instagram does not approve one-off projects for yourself, they only give permission if you are creating an app or platform for many to use.
https://www.instagram.com/developer/authorization/
One-off Projects. If you are an agency building websites or other
integrations, note that we don't grant permissions to clients created
for one-off projects. If you are interested in building a product,
platform, or widget that will be used as a service across multiple
projects, then you may submit a single client_id that you can use
across multiple projects.
If you are creating an app/platform you have to have a login flow for each customer to login and use, so you have show login flow in video screencast.
If you are not building an app/platform for wide audience, you probably will not get permission and are expected to use other apps out there that do what you want to do.
Also checkout the Instagram Graph API, this is API for business accounts to create one-off projects to moderate your accounts, but you will not have access to public hashtag posts, you will have access to all content for your account: https://developers.facebook.com/docs/instagram-api/v2.10
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 6 years ago.
Improve this question
I recently entertained the idea of developing an app that aggregates Instagram data of a small community and displays it in different UI clusters, derived by certain analytics. While the API provides all the required endpoints for my requirements, I started re-inventing the app over and over again, to satisfy the Instagram platform policy, terms and conditions as well as the login permissions for the different scopes.
According to Instagram API documentation there are 3 categories for the scopes of all apps:
To help individuals share their own content with 3rd party apps: basic
This use case is meant for apps that allow the general public to login with Instagram to get their own content; for example, an app that allows people to print their own pictures. Apps that fall into this use case will only have access to the basic permission.
To help brands and advertisers understand and manage their audience and digital media rights: basic, public_content, comments, relationships, likes, follower_list
This use case is meant for products that don't have a public facing login integration, but are gated to brands and advertisers. The product must support either multiple brands and advertisers (e.g. a social media management platform) or multiple users within a single brand or advertiser organisation.
To help broadcasters and publishers discover content, get digital rights to media, and share media with proper attribution: basic, public_content, comments
This use case is meant for products that don't have a public facing login integration, but are gated to broadcasters and publishers. The product must support either multiple broadcasters and publishers, or multiple users within a single broadcasters or publisher organization.
Ideally, my app would benefit as many analytical endpoints as possible, particularly if I can process the list of followers and public content. This means my app should fall under group (2). However, the target community of this app was not consisted of brands and advertisers. Group (3) is also not an option, since my community is consisted of individuals. Then I was thinking that group (1) will fit my needs. But that was also not the case, since according to platform policy, I won't be allowed to put the media in different UI clusters:
You cannot replicate the core user experience of the Instagram apps or web site. For example, do not build a media viewer.
Then I started comparing the use cases with existing live apps. I noticed that if they would carefully follow the terms and conditions, as well as platform policies, they would also be unfit for all rules imposed by Instagram. Let me provide examples:
minter.io (broadcasters == individuals?)
minter.io focuses on Instagram analytics. Thus, it falls in group (2). However, anyone can register on this system, meaning any individual that owns an Instagram account. How is this a valid case when brands and advertisers are not gated? Furthermore, even if those are somehow filtered in some future phase (which they claim they do manually), why is it allowed to generate a report of a "competitor" account, when the ID of that account could be any individual, and not an advertiser?
pikore.com (discover / search function?)
Apart from having the similar issues of minter.io, where everyone can login, I fail to understand how is it possible for pikore.com to provide a "discover" functionality which is exactly what Instagram offers on its mobile apps? Is that not breach of platform policy? Or the fact that it is also able to display all media items of a given account mixed with advertisement? For example: pikore.com/arianagrande. This breaches also other terms stated in General Terms of Platform Policy:
24. Add something unique to the community. Don't use the Instagram APIs to replicate or attempt to replace the functionality or essential user experiences of Instagram.com or any of Instagram's apps.
25. Respect the way Instagram looks and functions. Don't offer experiences that change it.
26. Don't attempt to build an ad network on Instagram.
ElseWatcher (another media viewer?)
I absolutely adore this app. But the fact that the Instagram data is organized by location and date, it seems to me that it's another media viewer with extra functionalities.
socialbakers.com (free social tracker?)
socialbakers.com, while providing an amazing interface, it requests public_content scope for any individual user of instagram.com. On top of that, without providing any mechanism to gate the broadcasters, offers their services as "Free Instagram Analytics Tool".
Maybe I am wrong, but the way I see it, the Instagram API rules, are not applied consistently to all 3rd party apps. Can anyone explain whether those are inconsistencies indeed, or whether I got things the wrong way?
While at it, I would also like to know how is it possible to have the term clause "1. Instagram users own their media (stated here) in conjunction with "17. Don't apply computer vision technology to User Content, without our prior permission" (stated here). Does that mean that if I am an Instagram API user that agrees to these terms, and I perform computer vision on any image that also happens to be on Instagram, that I am breaching terms?
Have you seen this cases?
simplymeasured.com/freebies/instagram-analytics
pro.iconosquare.com/pricing
websta.me
unionmetrics.com/free-tools/instagram-account-checkup/
After June 1st all Instagram 3rd party apps should pass a review. The review should contain video screencast with
Provide a link to a video screencast showing the experience in your
app. Please show how your integration uses all permissions you are
requesting, any interface to moderate content or getting rights to
media, and any Instagram login experience. Since your app may be in
sandbox mode, you can use data from sandbox users to showcase the
integration.
I think, Instagram wouldn't have approved any app which violate their rules.
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.
I'm trying to create a Azure Mobile Services Backend (JS) for an Android App and Website, with Windows and iOS versions down the road.
I see that you can add API keys to Facebook, Twitter, Microsoft and Google for users to authenticate via social accounts. I want my app to enable registration and login from these social accounts as well as have a standalone sign up form should they opt not to.
All data should be stored in a user table and I want to be able to store columns like phone number, and have users login and manipulate data specific to their account via Mobile Services APIs.
Could a knight or dame in shining armor point me to the right direction on how I can implement this? I haven't been able to find any articles that can help me create such a system.
I'd start with this post by Chris Risner:
http://chrisrisner.com/Custom-Authentication-with-Azure-Mobile-Services-and-LensRocket
He links back to several earlier posts that should provide the background you need and also has some updates at the top to point you to changes since that post.
For profile information from the social providers I'd use these examples (and the associated links) from Carlos Figueira on how you can access more profile information from MS, Google, and Facebook.
http://blogs.msdn.com/b/carlosfigueira/archive/2013/12/12/expanded-login-scopes-in-azure-mobile-services.aspx