Is per-customer project provisioning with distributed API keys allowed?

Gemini API
1

Hi,

I’m building a paid desktop app (Electron + local Python backend) for teachers in
Korea. It extracts questions from exam PDFs using the Gemini API. The PDF pages are
sent from the user’s own computer directly to the Gemini API — they never pass
through any server of mine.

Today each customer creates their own Gemini API key and pays Google directly.
I’d like to simplify this for non-technical users by covering the AI cost myself.
The design I’m considering:

  1. Create a separate Google Cloud project for each customer
  2. Link each project to MY billing account (so I pay, not the customer)
  3. Set a per-project spend cap to bound the cost
  4. Issue one API key per project and place it in that customer’s app installation
  5. When a customer’s subscription ends, unlink billing / delete that key

My questions:

(a) Is it permitted under the Gemini API Additional Terms of Service to issue API
keys from projects I own and place them in end users’ installed applications?
The API key best-practices docs advise against embedding keys in client apps,
but I couldn’t find an explicit prohibition in the Terms. Is this a security
recommendation, or a Terms violation?

(b) If it is not permitted, is there a supported way for a developer to pay for
end users’ Gemini API usage without proxying their content through the
developer’s servers?

(c) Are there limits I should know about on the number of projects that can be
linked to a single billing account for this pattern?

Thanks!

2

(a) Is it permitted under the Gemini API Additional Terms of Service to issue API keys from projects I own and place them in end users’ installed applications? Is this a security recommendation, or a Terms violation?**

Unfortunately, we cannot offer legal advice or interpret the Terms of Service. You should review the official Gemini API Terms of Service directly.

However, from an architectural and security standpoint, we strongly advise against embedding API keys directly within client-side applications (such as Electron apps). Client-side code can be decompiled or inspected, making embedded API keys vulnerable to extraction and abuse by unauthorized third parties.

(b) If it is not permitted, is there a supported way for a developer to pay for end users’ Gemini API usage without proxying their content through the developer’s servers?

Consider exploring Firebase AI Logic , as it’s built around calling the Gemini API directly from an app rather than server-side.

(c) Are there limits I should know about on the number of projects that can be linked to a single billing account for this pattern?

N/A. Because we strongly recommend against embedding API keys for each end user, this architectural pattern should not be used.