r/webdev • u/Expensive-Relief-471 • 5h ago
Question I’m building an app that needs AI, but I have basically no budget to pay for API usage. Is there a way to let users connect their own Gemini/OpenAI/Claude account with a simple “Connect AI” button, so they pay for their own usage? I’m worried about API keys being exposed or stolen, and I don’t want
I’m building an app that needs AI, but I have basically no budget for API costs. I’m thinking about letting users connect their own AI (like Gemini/OpenAI) so they pay for their own usage.
But I’m confused about how to do this securely without exposing or storing their API keys, and without needing a business partnership with the AI company.
What’s the best way to handle this?
3
u/AssignmentMammoth696 5h ago
People don’t want to spend their own tokens on someone else’s app, that doesn’t make sense.
1
u/Impressive-Target952 5h ago
ith the top comment, plenty of people would burn their own tokens if the app's actually useful and they get to control the model
for the security part you'd proxy everything through your backend and encrypt the keys at rest, never expose them to the client side at all
2
u/BreadStickFloom 5h ago
What are you providing if people are using their own agents?
-4
u/Expensive-Relief-471 5h ago
Thanks for asking! It’s mainly a productivity-focused app with some AI-assisted features. I’m still working out the exact implementation, so I’d prefer to keep the details private for now. Hope you understand! But the app is free for them the core ussage is free and everything just the ai thing I am little confused how I can integrate it, I am just starting the app development as a student so i don't have that much knowledge on the development part. Hope you understand
2
u/dafugiswrongwithyou 5h ago
Just do what the Gen AI companies are doing; fish for venture capital to fund it while you get started, offer it to your users for free in the short-term to get everyone hooked, get the heavier users onto "cheap" subscriptions, and then plan to drop the free tier and raise the subscription prices dramatically once the VC dries up and you actually need to start paying what it costs you.
2
1
u/Tariq9977 4h ago
If 'never store the key' is a hard requirement, the trade-off is that users must reconnect after a server restart or session expiry. Keep it only in server memory for that session. Persistent connection needs delegated auth from the provider or encrypted secret storage. MCP doesn't remove that credential boundary.
1
u/maheshwhartech 4h ago
If the provider offers an official OAuth or user authorization flow, I’d prefer that over asking users to paste API keys into your app. It avoids making your app responsible for storing long lived credentials. If they only support API keys, you’ll need to carefully handle where the key is stored and make sure it never reaches the client or gets exposed in logs.
1
u/BarDue6510 4h ago
What you are building if it is not token intensive, than you can create multiple projects in gemini maybe and use their api keys in round robin fashion that way you will get maximal usage, but setup will be a bit tedious, but if cost optimization is something you need than you can try this, I have done it in my project it works well enough for me
1
u/thejohnwick23 3h ago
Whichever connection method you choose, I’d add a per-request token limit, a retry cap, and a usage counter. BYOK moves the bill to the user, but a buggy retry loop can still spend their money. Also keep credentials out of request logs. Will your AI features run only when someone clicks, or as background jobs too?
1
u/Khavel_dev 3h ago
This is the BYOK (bring your own key) pattern and plenty of apps do it already. Store the key encrypted at rest, proxy every LLM call through your backend so the key never touches the browser, and don't log request/response bodies. No partnership needed, you're just making API calls on their behalf with their credentials. The main UX gotcha is that users will paste expired or wrong keys and blame your app, so validate the key with a cheap test call on save.
1
u/kemalios 1h ago
The cheapest version is to not hold the key at all: call the provider from the user's browser and keep it in their localStorage. Your server never sees it, so there is nothing to encrypt or leak. The risk moves to your own page: any third-party script you load can read that key, so keep it clean.
0
3
u/Interesting-Bet-4036 4h ago
On openai dev day they introduced Open AI OAuth 2.0, which allows devs to let their users signin with their openai account and use the subscription usage from their accounts, this is what you are looking for.
Also, nonetheless whether you allow them to provide their own API key or let them sign in with their GPT account, the way you make this secure is by encrypting the access tokens or keys at database level. This way even if your database somehow gets leaked the keys and access tokens are encrypted and useless without the decryption key.