Consider a desktop application that interacts with a web API, for which it needs a key. How should API keys be handled? Configuration files come to mind, however it doesn't seem that simple when terms of use of APIs are factored in.

Specifically, the following two examples of APIs:

  • ISBN Database https://isbndb.com/isbn-database - there is a "basic" plan, limited to 5000 daily calls.
  • News API https://newsapi.org/pricing - there is a "developer" plan, which permits "all testing and development of personal or commercial projects.". Note that any of the paid plans only mention commercial projects.

Is it feasible to make open-sourced applications using these APIs with the mentioned plans work "out-of-the-box", in line with the terms of use? Or, would it be limited to telling users to obtain their own key and configure the application themselves?


From a software engineering point of view, others have explained that shipping source code with an API key is a rather bad idea. If you have to meet the terms of some open source license, then you need to check whether shipping source code that you know doesn’t work out of the box is Ok according to the license.

Of course you could add some code that lets an end user enter an API key which is probably legal but highly inconvenient.

| improve this answer | |
  • 2
    To my knowledge, there are no (widely used) licenses that require all licensed code to be in working condition. That would probably mean that as soon as a critical bug is discovered in that software (or any bug at all, depending on how a lawyer interprets "working code"), the software would be in violation of the license. – Bart van Ingen Schenau Jul 20 at 13:38

ISBN Database https://isbndb.com/isbn-database - there is a "basic" plan, limited to 5000 daily calls (more than enough for the intended use).

How do you know that 5000 daily requests is enough for the intended use, when your software is open source and you have no way of knowing who uses it or how heavily they use it?

If the key is in your source, then everyone will be using the same key. Let's be realistic here, people are not going to replace an API key if the original API key already works.

Given enough popularity of your projects, that key will be saturated and effectively unusable for any new consumers of your open source project.

That's even worse than not having a key at all, because now your new consumers have to troubleshoot your project out of the box.

If you had not provided a key at all, then the situation would've been better all-round:

  • Consumers who need more than a free key provides are immediately prompted to buy their own key.
  • Consumers who are happy enough with a free key at least use their own free key, meaning your consumers aren't sharing the same free key.

While this does slightly raise the threshold on getting your open source project up and running as a new consumer; the threshold would be raised even higher once the key you provided would be saturated by existing consumers.

So, to rephrase your original question with the information we just explored, what seems best to you:

  • Each consumer needs to manage their own key, free or not.
  • Consumers fight over the usage of the same key, i.e. the one you provided. Whether they hit the limit or not depends on how early in the day they fire their requests, and anyone who is "too late" must now troubleshoot the application only to then realize than they have to manage their own key, free or not.

The first option is a much fairer distribution of effort among your consumers, and avoids unpredictable availability of your provided API key.

That being said, do of course make it clear that these key need to be provided by the consumer. Whether you force it via an initialization parameter or heavily document it, is a matter of how your project works and whether access to a given resource is essential to the application's core purpose or whether it merely provides an additional feature that could be skipped.

| improve this answer | |

If you use a rate limited, or charged per request API in your project you need to hide that API behind one of your own rather than use it directly.

This is somewhat obvious when you consider public websites, but lets consider your desktop software used within a single company example.

Here, the company has API keys for the APIs and the desktop software could connect direct to the APIs, keeping the key in its config. You wouldn't worry too much about the key being stolen, all the machines are firewalled, you trust your staff etc etc.

However, say one user uses the software far more than others. Either for legitimate reasons; they are doing reports and need to do lots and lots of queries, Or perhaps they are just being lazy about caching, or maybe they are just bored and hitting f5 alot.

They will use up your daily quota and prevent all the other users from being bale to work.

If you add an internal API between your desktop software and the third party API you can manage this by adding extra per machine or user quotas, extra caching etc etc.

Caching and limiting the API queries over all your end users or clients, will enable you to get the most efficient use of your limited quota of 3rd party calls.

We can also consider the case of a single user application. Here you might be tempted to say "just buy your own api key and enter it here" and this might be fine for some APIs. For example the ISBN one charges a fee for its basic account and would probably be happy to sell one to each user separately.

However, I would say for most APIs the expected use case is multiple users. They will not be happy with organisations using multiple free tier licences instead of a single paid for licence and their terms and conditions will be structured to prevent this.

Your single user application could be caught out by these conditions, or the 3rd party might consider your software effectively a single client product that should be considered as a single organisation rather than many single users.

In either case, added the intermediate layer as part of the software allows you multiple options.

  • each user purchases their own key

  • each user has a single key for their organisation

  • you buy a premium key and resell it via a published intermediate api.

    For instance the 'pro' isbn key gives you 50k for $50 vs 5k for $10. If your users use 2k each and you can cut that even further with caching, then you can wrap the service and sell access at a profit.

| improve this answer | |
  • What I gather from this, is that sharing an rate-limited API key, such as the ISBN DB API, would be permissible, but strongly discouraged (for the reasons you mentioned). Is this an accurate statement? – Al2110 Jul 20 at 12:05
  • 1
    I get the feeling that this answer missed the open source context here. OP isn't providing a public internet service whereby his own deployed application serves all consumers (connecting them to the API-locked resource), OP is providing open source code to consumers, who will then run the application for themselves and thus directly connect to the API-locked resource (without OP's involvement - other than having written the code that does so). – Flater Jul 20 at 12:47
  • I did think of this, but Its really beside the point whether the source code is distrubted or not. The intermediary Api should be part of the solution regardless. – Ewan Jul 20 at 12:51
  • @Ewan: The distribution of the source code is exactly what promts this question in the first place. You're discarding the core use case. – Flater Jul 20 at 12:53
  • 1
    @Ewan I take your point regarding the intermediary API. However, I'm not sure how this could be implemented. What technologies/solutions could be used? For context, it is a .NET desktop application. It may be that the intermediary API is too much of a hassle, so asking users to obtain their own key might be the way to go. – Al2110 Jul 20 at 12:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.