I’m interested in potentially building an application where users can enter their own OpenAI API key into my application and use the service that way. This key may be stored in a database by my application. I’m wondering what is the OpenAI policy on letting users bring their own key? Is there any commercialization challenges and restrictions in doing so? Maybe guidelines on best practices which could be helpful I could check out?
Thank you!
Thanks for checking. For security purposes, users are not permitted to share their API keys with others, including via bring-your-own-key applications.
We will work to make this clearer in our documentation; we are also considering technical solutions that may allow users to authenticate with a service without sharing their actual API key.
I hate to revive an old discussion, but if the app does not collect the key but leaves them on the user’s local machine in a hashed session cookie? Is there updated info on this? For some reason this was all I found. I’m just trying to find a way to let users test an app for safety before we launch. We have no way for people to pay atm. Thank you in advance. 
Yes, that would be permitted. Please check our guidelines on bring-your-own-key applications. Also, you’re not required to go through the app review process if you’re only testing with less than 10 users. Hope this helps
Hello, Ishant.
I’ve got my app reviewed by you only.
My question is:
My (coming up) service will allow businesses to build chatbots, all following the due diligence under the guidelines.
And the service will act as a hosting provider to the chatbot for the businesses. In that case, the API tokens will be stored in environment variables on the servers, having proper oversight over the workings.
That should be allowed? as it’s mentioned on the site.
As per Documentation:
- The application may not store end-users’ API keys server-side or otherwise access end-users’ API keys in an ongoing fashion.
You will probably need to use your own key and charge users based on their usage. If you’re not sure if they’ll pay, have them “charge up” the account via credit card, etc in the first place and then deduct the usage.
What this also means is that since they’re using your key, if some of your customers produce harmful content in a repeated manner, your key may be revoked and your entire business falls apart. Always pass the content through the OpenAI content filter API first and evaluate if it’s considered ‘safe’. If not, you can set up your own flag/ban system. Better safe (banning a single customer) than sorry (getting your key revoked).
Thanks, Fusseldieb,
I’m doing exactly same as you’ve pointed out for my end-user consumption app. Charging for the tokens beforehand them using it as a credit balance.
I just wanted it to be clear if I can use other probable ways when offering the service to businesses. You’re right, I’m using the CF from day 1.
And will probably shift to a moderation endpoint that is better than CF.
Oh, thanks so much! Great news. 
Hi @ishant.singh,
Thank you for sharing this info! I had a couple follow up questions on this topic.
Curious if Apple Shortcut ‘applications’ would need to go through an app review process? Apps would be BYOK with users API keys stored in their iCloud accounts (via shortcut setup questions).
To make setup simple and easy, I’m hoping to point users to sign up with OpenAI and obtain their own API keys. Is it possible to hyperlink OpenAI’s website on our website (IE: a “View your Secret API Key” button)? Or does that trigger the following: “If you plan to mention OpenAI in your launch materials, please coordinate with our Communications team…” Let me know if that would be acceptable, excited to launch. 
Thank you again for your help!
Hi Ishant! Apologies for reviving an old thread. The guidelines on bring-your-own-key applications page that you linked to redirects to the new “Usage policies” page which doesn’t provide details on this anymore.
So I want to demonstrate a scenario here (of how the API key is used in my app):
The users API key is stored in browser’s local session storage and is only transmitted to the server (encrypted with server’s public key in transit and decrypted server-side) when the user uses the service actively and only for those requests triggered by the user explicitly. The API key isn’t stored in the server/backend. Is this use-case permitted?
It doesn’t make any sense for App developers to charge for API usage from users to recover costs and pay it forward to OpenAI when users can directly pay OpenAI instead. It would simplify workflow a lot and remove burden on devs. Makes no sense for us to implement usage based billing for this (when most SaaS apps already provide a way to BYOK).
Really need more clarity on this in the “Usage policies” document as it seems to have replaced the earlier guidelines for BYOK apps but no longer makes any mention of the same.
Thanks!
The documentation you’re referencing isn’t related to the issues you raise here @ishant.singh
@shripadkrishna I have the same problem. I have a free app that’s using my key. I want it to stay free, but not charge my account. If you managed to work out a secure and local api_key storage solution I’d love to hear more.
I suspect the “bring your own key” model is problematic to OpenAI because they won’t have control over the app developer, but I want to build a free app that doesn’t require user data or registration, so what am I to do?
Sorry for the delay. I saw your message today. Yeah I noticed many apps require API key from users and store it encrypted in a data store in the backend (AES256-GCM). I prefer this method over storing in browser session (which I mentioned in my earlier reply) as if the browser is accessed by someone else they can still retrieve the key stored in the local session storage (even if they haven’t logged in). Storing in the backend encrypted at rest would be much more safer IMHO.
Would very much prefer if OpenAI provides some sort of OAuth functionality with session tokens with some reasonable expiry (30 minutes or something of that sort) along with refresh tokens (24 hours expiry would be good). Users/app developers even control access to certain features with scopes. That way we don’t have to ask for API keys from users either.
What if I have a desktop app, where users of my app need to re-inout their own api key via a textbox every time they use the app, and the key doesn’t get stored anywhere, would this be allowed?