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.