Understand developer-data privacy

The Privacy Policy is the source for approved retention periods and legal commitments. This guide covers the developer workflow: which identifiers you can use to diagnose a call, how to avoid sharing content, and what to do when a credential is exposed. It does not add a separate retention promise.

Review activity without content

Sign in to the organization that owns the key and open API Activity. The list shows the model, endpoint, outcome, duration, input and output tokens, the finalized credit debit and the run ID. The run ID differs from the HTTP request-id header; keep both in their own fields if you correlate client and account records. Activity does not show prompts, responses, full API keys, the key name or internal execution details. The raw key appears only once at creation in API keys; afterward the list shows metadata. Access to one organization's activity must not be treated as access to another organization's records.

An Activity row is a diagnostic record, not a statement that no content exists anywhere. Web chat persists conversation items. Responses defaults to store: true, which can persist a sanitized response for later retrieval; set store: false explicitly to prevent later retrieval of the completed response by ID. During generation, a request attached to a persistent conversation can still expose partial output through that ID and add conversation items. An explicit Idempotency-Key can retain the terminal payload for safe replay even with store: false; safe operation and accounting metadata are recorded in either case. Use the API storage rules, idempotency guide and Privacy Policy when choosing how to handle content.

Prepare a support report

Record the time and timezone, endpoint, public model ID when relevant, HTTP request-id, safe public error code and whether the call used streaming. These values help distinguish a transport failure from an API rejection. Do not attach the request body, generated response, API key, browser cookie, OAuth token, CLI credential-store value, environment dump or raw internal error. Redact sensitive application data before sharing a screenshot or console log. Errors and limits explains how to interpret the public code.

If you use a client-side logger, keep only this allowlisted record and never log authorization headers or complete request and response objects. A screenshot of a terminal can contain shell history, clipboard values and local file paths: inspect the entire image before sending it. When you cannot redact a log safely, describe the status and code in words instead.

Respond to exposure

If a key has appeared in a repository, log, ticket or screenshot, treat it as exposed. Revoke the affected key, create a replacement, update its clients and verify the replacement using the free model catalog. Review account security separately for browser sessions and CLI grants; those are different credentials. Do not paste the exposed value into a report to prove which key it was. Use the key's safe list metadata or ID instead.

If the secret was embedded in deployed configuration, replace it at its approved secret store and restart or redeploy the affected workload through your normal change process. Removing a line from a repository does not make an already copied key safe. Confirm the old key is inactive and check the client's next call before closing the incident.

For retention, deletion rights and legal details, return to the Privacy Policy. For the available operational fields, use the Activity guide.