Hello, I have a desktop application built with c# and want to integrate chatgpt into it. I want each user to use their own api key in my app because using my own key for all users would be Extremely impractical as it would he really hard to charge each user myself for token usage and then pay for usage, and some users could abuse my own key,
So I want each user to input their key into my app, the key will not be stored anywhere, wont be stored on any server and wont be stored on clients machine either. And user would re-input it every time they use the app. Is this allowed?
Thank you, I asked because of that
1 Like
This doesn’t make sense. When I first started with OpenAI, I did not have my own server. I connected with someone who did have a working chat completion system, and used my key there. You’re telling me that this violates the OpenAI terms of service? So, everyone who wants to obtain an OpenAI API key has to have their own API infrastructure in place, or else they can’t use the key? What about renting/leasing the infrastructure?
And how, exactly, is placing the key in a cookie or otherwise embedding in browser safer than being stored in a secured server?
Ok ,the idea is (as I interpret it) the customer buys a service from you the service provider. You use the OpenAI API with your API key to fulfil their needs. Customer pays you, you pay OpenAI. The service you provide is 100% your output, you are responsible for that output. It is your responsibility to moderate your users usage and manage there expectations.
What the system is not set up for is 1 developer offering a service to other developers with API keys of their own. End users should not be using API keys to access the services. It is not user friendly and causes a great deal of confusion when technical issues occur that should be covered by a support team and system dedicated to that task and not the developer support team or a small team dedicated to keeping the technology running.
The API section of OpenAI want’s to be the backbone technology provider and not the front line customer facing provider, that would be the whole help.openai site and ChatGPT, plugins, etc, etc. Different section of the business.
2 Likes
Consider a good benchmark one can use:
Is the API key being used to connect directly between the owner of the key and the OpenAI API service?
or
Is the API key being used to connect to or employed by a third-party service that may decrypt, store, reuse, or call API on behalf of the user?
Fair enough. I then obtain a key under my license for an individual end-user. I’m technically re-selling the key. Now I’ve got to track token usage and bill monthly. Not so bad. But what happens when I get a bad actor who then takes that key and spreads it around runs up token usage and refuses to pay? Now I’m on the hook with a fraction of a fraction of the Gazillions of dollars OpenAI has to deal with these types of issues.
And all I’m trying to do here is make the process a little less expensive for the end user – now they simply “pay as you go” rather than frontloading anticipated usage costs on top of service costs each month.
Does any of this make sense?
Yes. The first case.
The use case I have in mind is that the API key the user brings is ONLY used by the user who brings it. Period. No one else has access, unless the end user shares it with them. Which, of course, we highly discourage.
You must do everything you want to do with client-side code that connects directly to the API.
You must not use the key yourself or attempt to gather (except a secure datastore local to the user only), as then the user’s sharing of the key would be in violation of the terms of service.
(c) Restrictions. You may not (vi) buy, sell, or transfer API keys without our prior consent
The “bring your own key” forum post clarified this.
In our case, the API key is not handled on the client side. Only the server side. It is tied to the user’s account, so I don’t see how “transfer” applies here. But, “prior consent” seems fair. How do we go about getting that?
Can you provide a link to that post?
The link again is here: https://community.openai.com/t/openais-bring-your-own-key-policy/14538/2
ishant.singh - OpenAI Staff
Thanks for checking. For security purposes, users are not permitted to share their API keys with others, including via bring-your-own-key applications.
If a hack of your service would expose user’s API keys - or if you are able to obtain them in any way at all being the sysadmin – because they are being sent to you, than again, a .
See other topics here you can search along the lines of “my account was deactivated and banned because I put my API key into the janitor.ai service”
1 Like
Not really, you should never resell an API key or any variant of that.
You sell a service. Your product solves a customer need, they sign up to your business, to your account system and you handle their account as you see fit, typically they have a username and password, that is “their login” the way they access your service.
You as a service provider now have to handle “bad actors”. You build moderation systems that take advantage of the moderation endpoint, you build custom keyword triggers, you build moderation systems that take advantage of the floating point “score” numbers returned by the moderation endpoint, so that you can detect violations that are below the threshold for a TRUE/FALSE moderation check.
You are not selling access to OpenAI’s AI, you are selling access to your service that is built atop those subsystems.
2 Likes
Well, there goes the bargain basement inexpensive route.
1 Like
Fine. But I still have trouble wrapping my head around the fact that a user can use my key all day long to make API calls, but I am prohibited from using that same user’s own key for making those vary same API calls. Always something.
Thank you for the link.
The secret is, you charge them for the service you give, more than OpenAI charges you… voila! They can use the API all day long and you don’t loose.
Another way to do this is to do usage modelling, not all users will use your service 24/7 and if they do… you have penalty clauses in place for excessive use, or you have a rate limit, or you charge them for extra usage over an above the standard allowance. If you get an idea for what your average customer will use, then you can calculate a fixed monthly fee that takes into account the majority of users and also those edge cases of users who use much less and those who use more more.
Yes this does get more complex and involved, but it is the way you build value, you provide a service that end users trust, but you need to offer them something they want, be that entertainment, money savings, time savings… status symbols… all of the myriad things that people want from life.
2 Likes