Open-sourcing applications with API keys

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.

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.

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.