Question
This is a task, not a decision. It exists only to unblock one, and it is yours to do — an agent must not contact a vendor on your behalf.
#690 cleared Services Agreement §3.3(g) as far as public documents allow, and found two things that reading cannot settle:
- whether §3.3(g)'s undefined "transfer … to … a third party" reaches a user entering their own key into locally-installed software;
- the harder one — whether Service terms §1 ("use APIs in accordance with the applicable documentation") makes the API reference's "Don't … expose it in any client-side code such as browsers or apps" a contractual obligation, and whether a hardware-backed keystore counts as "exposure".
Neither is answerable from the documents. Both are answerable by OpenAI support, from your own account.
Ask the documentation question first — a concrete "is this pattern acceptable" enquiry is far likelier to get a substantive reply than a request to interpret a contract clause, which support routinely declines.
Draft enquiry
Subject: Is a user-supplied API key in an open-source mobile app compatible with the Services Agreement and API documentation?
I maintain OpenNutriTracker, an open-source (GPL-3.0) nutrition tracking app for Android and iOS. I would like to offer OpenAI as an optional provider using a bring-your-own-key design, and want to confirm it is acceptable before shipping it.
How it works:
- The user creates their own OpenAI account and API key and pays OpenAI directly. I have no relationship to their usage, operate no server, and never receive or see their key.
- The key is entered by the user, in the app, on their own device, and stored in the platform keystore (Android Keystore / iOS Keychain).
- It is sent only as a Bearer token to
api.openai.com. There is no backend and no proxy. No key is embedded in the application binary.
Two questions:
- The API reference states: "Don't share it with others or expose it in any client-side code such as browsers or apps. Load API keys from an environment variable or key management service on the server." Service terms §1 requires use "in accordance with the applicable documentation". Is that guidance a contractual requirement, and does a user storing their own key in their device's hardware-backed keystore constitute "exposure" for this purpose?
- Services Agreement §3.3(g) prohibits Customer from "buy, sell, or transfer API keys from, to, or with a third party." Does a user entering their own key into locally-installed third-party software constitute a transfer to a third party, given the key remains on their device and is transmitted only to OpenAI?
If the client-side pattern is not acceptable for mobile applications, is there a sanctioned alternative for an application with no server component? The documented approach for mobile clients appears to be server-minted ephemeral credentials, which an application without a backend cannot implement.
Record here whatever comes back — including "no substantive answer", which is itself a result the map has to act on. If OpenAI declines to interpret, note that and the decision passes back to the maintainer as an accepted risk, to be recorded rather than resolved.
Do not send an API key, account identifier or billing detail in the enquiry. None of the questions needs one.
Question
This is a task, not a decision. It exists only to unblock one, and it is yours to do — an agent must not contact a vendor on your behalf.
#690 cleared Services Agreement §3.3(g) as far as public documents allow, and found two things that reading cannot settle:
Neither is answerable from the documents. Both are answerable by OpenAI support, from your own account.
Ask the documentation question first — a concrete "is this pattern acceptable" enquiry is far likelier to get a substantive reply than a request to interpret a contract clause, which support routinely declines.
Draft enquiry
Record here whatever comes back — including "no substantive answer", which is itself a result the map has to act on. If OpenAI declines to interpret, note that and the decision passes back to the maintainer as an accepted risk, to be recorded rather than resolved.
Do not send an API key, account identifier or billing detail in the enquiry. None of the questions needs one.