Hello, I am a PHP developer and I’d like to make an app, I wanted to make it open source and public (as in being available on the web) at the same time, but I don’t want to put the API key in and get charged a lot of money, due to the nature of my app, the AI will make a very large token amount, It’s a TOS generator, you see. So, I wanted to ask, is it okay to take in the user’s API key, store it in a variable for that request, interact with the AI, on behalf of the user, and then dump the request after the user’s request was completed?
For those familiar with PHP: I live Laravel and Livewire, plus openai-php/client. If this is not allowed as per the ToS, I will probably just not self host it publicly and make it where you put the api key into the .env.
Is there substantial documentation and evidence that OpenAI forbids this? Yes.
I don’t think it’s even a matter of whether or not you save it to a database. It’s a matter of exposing API keys in any way to those outside of your organization/account.
This is a bad idea. You do not want to hold responsibility, even for a moment. This is a bad infrastructure.
If you want to perform actions on behalf of the user’s account you should make the program completely client-side. Even then, it should be open-source for peace of mind.
So, OpenAI doesn’t want people to give their API keys to “other people.”
They forbid this, so that they can easily disable keys that get abused, and point at the ToS as justification.
This makes total sense.
However, while a server-side app renderer would technically fall within the text in the ToS, if it’s not getting abused, OpenAI won’t do anything to you.
After all, what COULD they do? They can ban API keys, but they can’t, like, ban GitHub repos …
If you make the request server side, they could conceivably ban your IP address, though, which is something you may decide is fine if it were to ever happen. Good rate limits would probably prevent that in practice.
So, I’ll go against the other two suggestions. If I were building an app like this, I think I would be fine, especially if I had some rate limits in the app, and followed the spirit of the limitation. The worst case if something goes wrong really doesn’t seem particularly bad for me as far as I can tell, as far as technical implementation and results go.
If OP is running people’s API keys on behalf of the user (which is definitely not allowed) they are taking a tremendous amount of responsibility for … nothing.
If you take people’s house keys, and then one day their house gets broken into, you’re in the line of sight.
Let’s say OP is running a very insecure server. Hackers get a hold of the logs and see ALL the API keys that were ever used. We’re talking a potential of thousands of dollars ripped away from people who didn’t know any better.
If the OP wants people to use their own API keys then they should stay out of their business and allow the complete operation to happen on the client-side.
The disadvantages & liabilities GREATLY outweigh the advantages here.
Hello, thanks for your insight. You’re right, unfortunately I didn’t really consider the idea that Laravel will remember logs, and by extension, apache as well. I figured it was like, “If you don’t save it” not “You can’t use someone’s api key” so, that is a sincere mistake on my part, my apologies, it was just an idea I was tossing around, never yet became an actual product.