docs: correct DevPass data retention copy - #3383
Conversation
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
WalkthroughThe PR updates legal pages, the FAQ, and documentation to define metadata-only retention for DevPass and chat subscriptions. Standard pay-as-you-go organizations retain configurable settings. Stateful Responses API items can be retained for up to 30 days unless ChangesRetention policy documentation
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Pull request overview
Updates public DevPass and documentation copy to reflect the post-#3296 reality: DevPass/chat never store request/response payloads and do not expose a retention-level setting, while standard PAYG orgs can configure retention.
Changes:
- Add explicit “PAYG-only” retention caveats to docs pages that describe data retention behavior.
- Update DevPass legal terms/privacy language to remove references to a retention toggle and payload storage.
- Adjust DevPass FAQ copy to scope full retention to PAYG and clarify DevPass’s metadata-only behavior.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| apps/docs/content/learn/policies.mdx | Adds a note that retention level configuration applies only to standard PAYG orgs; DevPass/chat are metadata-only. |
| apps/docs/content/features/data-retention.mdx | Adds a warning callout and clarifies configuration scope as PAYG-only. |
| apps/code/src/components/Faq.tsx | Updates FAQ answer to scope optional retention to PAYG and mention DevPass metadata-only behavior. |
| apps/code/src/app/legal/terms/page.tsx | Updates DevPass terms to state only metadata is stored; payloads/responses are never stored. |
| apps/code/src/app/legal/privacy/page.tsx | Updates DevPass privacy policy to state payloads are never stored; removes retention-toggle language and bumps last-updated date. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| completes. There is no setting to turn payload storage on, on any | ||
| DevPass plan. The configurable data retention available on pay-as-you-go |
| { | ||
| question: "Do I need a subscription, or is there pay-as-you-go?", | ||
| answer: `Both work. DevPass plans turn every dollar into $3 of model usage. If you'd rather not subscribe, LLM Gateway offers pay-as-you-go: top up credits and pay per token at provider rates with a flat ${MARKETING_STATS.platformFee} platform fee, or bring your own provider keys for free. In both modes, optional full data retention is billed at ${MARKETING_STATS.dataStoragePrice}.`, | ||
| answer: `Both work. DevPass plans turn every dollar into $3 of model usage. If you'd rather not subscribe, LLM Gateway offers pay-as-you-go: top up credits and pay per token at provider rates with a flat ${MARKETING_STATS.platformFee} platform fee, or bring your own provider keys for free. Pay-as-you-go organizations can optionally enable full data retention, billed at ${MARKETING_STATS.dataStoragePrice}; DevPass never stores request payloads.`, |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@apps/code/src/app/legal/privacy/page.tsx`:
- Around line 77-84: Update the privacy policy paragraph text around the “There
is no setting” sentence to replace “turn payload storage on, on any DevPass
plan” with “enable payload storage on any DevPass plan,” preserving the
surrounding policy wording.
In `@apps/docs/content/features/data-retention.mdx`:
- Around line 27-33: Scope the retention claims to standard pay-as-you-go
organizations and explicitly exclude DevPass and chat subscriptions, which
remain metadata-only. Update the retention statements near the referenced
sections in apps/docs/content/features/data-retention.mdx and the policy
statement at apps/docs/content/learn/policies.mdx lines 24-25 to clarify that
payloads are never stored for those subscriptions and cannot be enabled through
organization settings.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro Plus
Run ID: b95b2de9-74e7-4d7e-ab6a-cb8e9ee35835
📒 Files selected for processing (5)
apps/code/src/app/legal/privacy/page.tsxapps/code/src/app/legal/terms/page.tsxapps/code/src/components/Faq.tsxapps/docs/content/features/data-retention.mdxapps/docs/content/learn/policies.mdx
| Full request and response <strong>payloads</strong> (your prompts and | ||
| the model output) are <strong>never stored</strong> on DevPass. DevPass | ||
| is metadata only: the counts, costs, and routing information listed | ||
| above are kept, and prompts and responses are discarded once the request | ||
| completes. There is no setting to turn payload storage on, on any | ||
| DevPass plan. The configurable data retention available on pay-as-you-go | ||
| LLM Gateway organizations does not apply to DevPass. | ||
| </p> |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Remove the duplicated preposition in the policy text.
Line 81 reads “turn payload storage on, on any DevPass plan.” Use “enable payload storage on any DevPass plan” for clearer legal text.
Suggested wording
- There is no setting to turn payload storage on, on any
- DevPass plan.
+ There is no setting to enable payload storage on any DevPass
+ plan.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| Full request and response <strong>payloads</strong> (your prompts and | |
| the model output) are <strong>never stored</strong> on DevPass. DevPass | |
| is metadata only: the counts, costs, and routing information listed | |
| above are kept, and prompts and responses are discarded once the request | |
| completes. There is no setting to turn payload storage on, on any | |
| DevPass plan. The configurable data retention available on pay-as-you-go | |
| LLM Gateway organizations does not apply to DevPass. | |
| </p> | |
| Full request and response <strong>payloads</strong> (your prompts and | |
| the model output) are <strong>never stored</strong> on DevPass. DevPass | |
| is metadata only: the counts, costs, and routing information listed | |
| above are kept, and prompts and responses are discarded once the request | |
| completes. There is no setting to enable payload storage on any DevPass | |
| plan. The configurable data retention available on pay-as-you-go | |
| LLM Gateway organizations does not apply to DevPass. | |
| </p> |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@apps/code/src/app/legal/privacy/page.tsx` around lines 77 - 84, Update the
privacy policy paragraph text around the “There is no setting” sentence to
replace “turn payload storage on, on any DevPass plan” with “enable payload
storage on any DevPass plan,” preserving the surrounding policy wording.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@apps/code/src/app/legal/privacy/page.tsx`:
- Around line 86-93: Update the Responses API privacy text near the “Exception —
the Responses API” section to remove the claim that the 30-day automatic
deletion behavior matches OpenAI’s retention. Keep the stated storage and
deletion policy unchanged unless it is supported by an explicit provider
contract.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro Plus
Run ID: fed53fc2-0eba-46f4-bba7-a9a03f183efe
📒 Files selected for processing (5)
apps/code/src/app/legal/privacy/page.tsxapps/code/src/app/legal/terms/page.tsxapps/code/src/components/Faq.tsxapps/docs/content/features/data-retention.mdxapps/docs/content/learn/policies.mdx
🚧 Files skipped from review as they are similar to previous changes (4)
- apps/docs/content/learn/policies.mdx
- apps/code/src/app/legal/terms/page.tsx
- apps/docs/content/features/data-retention.mdx
- apps/code/src/components/Faq.tsx
| <strong>Exception — the Responses API.</strong> Requests to{" "} | ||
| <code>/v1/responses</code> (used by tools such as Codex CLI) are | ||
| stateful by design: so that <code>previous_response_id</code> chaining | ||
| and <code>GET /v1/responses/{id}</code> work, the input and | ||
| output items of those requests are held in dedicated storage for up to{" "} | ||
| <strong>30 days</strong>, after which they are automatically deleted. | ||
| This applies regardless of retention settings and matches OpenAI’s | ||
| own Responses API retention. Send <code>store: false</code> with the |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🌐 Web query:
OpenAI Responses API response data stored for at least 30 days deleted after 30 days
💡 Result:
OpenAI's standard data retention policy for API usage, specifically regarding abuse monitoring logs, is that customer content (including prompts and responses) is retained for up to 30 days [1][2]. After this 30-day period, these logs are automatically removed from OpenAI's systems, unless retention is required by law or necessary for the protection of services or third parties [1][2]. It is important to distinguish between different types of data and retention controls: 1. Abuse Monitoring Logs: By default, API requests and responses are stored in logs for up to 30 days for abuse monitoring [1]. 2. Zero Data Retention (ZDR): Customers eligible for and approved for Zero Data Retention or modified abuse monitoring controls can exclude their content from these standard logs [1][2]. For ZDR-eligible endpoints, inputs and outputs are not retained for application state and are not logged for abuse monitoring [1][2]. 3. Other Endpoints: Some endpoints or features have different retention behaviors. For example, data sent to certain endpoints like /v1/conversations may be retained "until deleted," rather than being subject to a 30-day expiration [1]. 4. Developer Controls: For specific features that support it, developers may have options (such as a store parameter) to explicitly manage whether certain response objects are persisted [3]. In summary, while the default behavior for standard API abuse monitoring logs is to delete data after 30 days, actual retention behavior depends on the specific endpoint, the user's configured data retention settings (such as ZDR), and the nature of the service being used [1][2]. Official OpenAI documentation on data controls provides a breakdown of retention by endpoint [1].
Citations:
- 1: https://developers.openai.com/api/docs/guides/your-data
- 2: https://openai.com/index/response-to-nyt-data-demands/
- 3: https://community.openai.com/t/data-retention-for-model-response-need-clarification/1355501
🌐 Web query:
site:platform.openai.com/docs Responses API response data stored for at least 30 days
💡 Result:
There is no publicly available authoritative documentation or standard technical specification for an API specifically named Responses API that mandates the storage of response data for at least 30 days. The term Responses API is generic and may refer to various proprietary internal systems or third-party services that do not share a common data retention policy. Because there are no specific results regarding an API by this name with a 30-day retention requirement, it is not possible to verify such a policy.
Citations:
🌐 Web query:
site:platform.openai.com/docs/ responses API response data retention 30 days
💡 Result:
There is no standardized or universal 30-day data retention policy for API responses across the industry. Data retention practices are specific to each service provider, the type of data being handled, and the terms of service for the particular API. Technical documentation for specific APIs, such as the OpenAI API, does not cite a general 30-day retention policy for all response data [1]. When using services that store data, such as threads or run steps, you should consult the specific data retention and privacy policies provided by the platform developer [1]. If you are developing an application that uses an API, you are generally responsible for defining and implementing your own data retention policy for any response data you choose to store in your own systems. If you have a specific API in mind, please check its official documentation under sections typically labeled Data Retention, Privacy, or Compliance.
Citations:
🌐 Web query:
"Responses API" "stored for at least 30 days" OpenAI
💡 Result:
OpenAI retains data processed through its API services based on the specific endpoint used and organizational configurations [1][2]. Regarding the Responses API and general API usage, OpenAI's retention policies are as follows: Abuse Monitoring By default, OpenAI retains API inputs and responses for up to 30 days for the purpose of monitoring for abuse and ensuring the safety of its services [1][2][3]. This retention is standard unless otherwise required by law or necessary to protect services from harm [1]. Application State and the 'store' Parameter For specific endpoints, such as the Responses API, OpenAI provides a 30-day retention period for application state, which occurs by default or when the 'store' parameter is set to 'true' [1]. When 'store' is enabled, the data is persisted, allowing it to be visible in the Logs tab of the dashboard and accessible for features like evals or distillation [4]. If the 'store' parameter is set to 'false' (which is the default for most API calls), the data is generally not retained for application state [1][4]. Zero Data Retention (ZDR) Organizations can apply for a Zero Data Retention (ZDR) program [1][3][5]. When ZDR is enabled for an organization, the 'store' parameter is effectively disabled (always treated as 'false'), and API request and response bodies are not persisted to logging mechanisms, existing only in memory to serve the request [1][3]. Summary of Retention In summary, unless an organization is enrolled in a Zero Data Retention program, API data (including responses) is typically stored for up to 30 days for abuse monitoring [1][2]. Data specifically flagged with 'store=true' or used in endpoints that retain application state is also held for at least 30 days [1].
Citations:
- 1: https://developers.openai.com/api/docs/guides/your-data
- 2: https://openai.com/index/response-to-nyt-data-demands/
- 3: https://community.openai.com/t/zero-retention-days-and-api-call-logging/1147377/5
- 4: the `store` parameter in `client.chat.completions.create` seems to control API call logging, description is not accurate? openai/openai-python#2762
- 5: https://openai.com/business-data/
🌐 Web query:
platform.openai.com/docs/models/default-usage-policies-by-endpoint Responses API store false
💡 Result:
Regarding the behavior of the store parameter in the OpenAI API, when you set store=false, you are instructing OpenAI not to retain the request and response data for purposes such as fine-tuning, analysis, or display in the usage dashboard logs [1][2]. Key points regarding this behavior include: 1. Default Behavior: By default, many API endpoints (such as /v1/chat/completions and the Responses API) may have data retention enabled, but this is distinct from training usage [1][3]. When store=false is explicitly set in your API call, the content is not retained for future use in distillation, evaluation, or dashboard logging [2]. 2. Zero Data Retention (ZDR): If your organization has Zero Data Retention (ZDR) enabled, the store parameter is effectively overridden; OpenAI will treat the request as store=false regardless of whether you attempt to set it to true [1]. In this configuration, input and output data are not logged or retained for application state [1][4]. 3. Abuse Monitoring: It is important to note that even when store=false is used, OpenAI retains abuse monitoring logs for up to 30 days to protect its services and comply with safety requirements [1]. These logs are processed separately from the application state data controlled by the store parameter [1]. In summary, setting store=false prevents the retention of data for your dashboard logs and model refinement processes, but it does not bypass the standard, limited-duration abuse monitoring logs maintained by OpenAI [1][2].
Citations:
- 1: https://developers.openai.com/api/docs/guides/your-data
- 2: the `store` parameter in `client.chat.completions.create` seems to control API call logging, description is not accurate? openai/openai-python#2762
- 3: https://developers.openai.com/api/docs/guides/migrate-to-responses
- 4: https://openai.com/index/response-to-nyt-data-demands/
🌐 Web query:
"your-data" "Responses API" "response data" "OpenAI"
💡 Result:
In the context of OpenAI's API documentation, "your data" typically refers to the information and inputs you provide to the models [1][2]. OpenAI has clear policies regarding how this data is handled, stored, and used [2][3]. Key points regarding "your data" and OpenAI's API include: Data Usage and Training: By default, data sent to the OpenAI API is not used to train or improve OpenAI's models [2][3]. This applies to both the Chat Completions API and the Responses API [2]. Data Retention: - For the Responses API and Chat Completions API, data is typically retained for up to 30 days for abuse monitoring purposes [2]. - The Responses API may store data for longer periods if the store parameter is set to true (which is the default behavior in some contexts) [2]. - For customers with sensitive applications, a Zero Data Retention (ZDR) policy may be available, which prevents the persistence of request and response bodies to logging mechanisms [2][3]. Data Controls: You can manage data retention and storage through the store parameter in relevant API endpoints [4][2]. For further control, enterprise users can inquire about ZDR policies via OpenAI's sales team or dedicated support channels [5]. Distinction from "On Your Data": It is important to distinguish the general concept of "your data" from specific features like "Azure OpenAI On Your Data" or other RAG (Retrieval-Augmented Generation) implementations [6]. If you are using platforms like Azure OpenAI, "On Your Data" is a specific feature that integrates your custom data sources, often returning specific fields like context or citations in the API response to indicate which documents were retrieved and used [6]. If you are encountering a specific field or error message referencing "your-data" in an API response, please verify if you are using a third-party wrapper, an Azure-specific integration, or a custom implementation, as "your-data" is not a standard, top-level field in the official OpenAI Chat Completions or Responses API JSON schemas [7][8][9][6].
Citations:
- 1: https://developers.openai.com/api/reference/resources/responses/
- 2: https://developers.openai.com/api/docs/guides/your-data
- 3: https://community.openai.com/t/does-the-openai-api-get-access-to-the-data-i-send-it-or-store-the-data/599538
- 4: https://developers.openai.com/api/docs/guides/migrate-to-responses
- 5: https://community.openai.com/t/data-privacy-with-openai-api/929399
- 6: https://learn.microsoft.com/en-us/azure/ai-foundry/openai/references/on-your-data
- 7: https://developers.openai.com/api/reference/resources/chat
- 8: https://github.com/openai/openai-openapi/blob/aa666df399355822163071bd1253f34744978f88/openapi.yaml
- 9: https://github.com/openai/openai-node/blob/5436f42d/src/resources/chat/completions/completions.ts
Correct the OpenAI retention comparison.
OpenAI documents Responses API response data as stored for at least 30 days. It does not promise deletion at 30 days. Remove the “matches OpenAI’s own Responses API retention” statement, or back it with a provider contract that explicitly supports the same deletion behavior.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@apps/code/src/app/legal/privacy/page.tsx` around lines 86 - 93, Update the
Responses API privacy text near the “Exception — the Responses API” section to
remove the claim that the 30-day automatic deletion behavior matches OpenAI’s
retention. Keep the stated storage and deletion policy unchanged unless it is
supported by an explicit provider contract.
Problem
A support-chat conversation had the assistant confidently tell a DevPass user that "Data Retention settings apply to DevPass too", complete with a Metadata Only / Retain All Data table, "default on Lite, Pro, Max", and "you can purge stored payloads at any time from settings".
None of that is true since #3296 (Jul 29, 2026), which removed the DevPass retention toggle entirely:
PATCH /organizations/{id}now rejectsretentionLevelfor any org whosekindis notdefault,getOrCreatePersonalOrg/getOrCreateChatOrgcreate orgs asretentionLevel: "none", and a migration forced existing devpass/chat orgs tonone.The assistant wasn't hallucinating from nothing — it was reading stale public copy. Its knowledge set is built from the live sitemaps of llmgateway.io, devpass.llmgateway.io, docs.llmgateway.io and chat.llmgateway.io (
apps/api/src/utils/chat-support-knowledge.ts), anddevpass.llmgateway.io/legal/privacystill described exactly that retention setting, phrase for phrase. Nothing in the docs stated the carve-out either, so the generic/features/data-retentionpage ("configured per organization") read as applying everywhere.The Responses API caveat
"Metadata only" is not the same as "nothing is ever stored", and the copy has to say so.
/v1/responsesis stateful by design:storeResponse()writes the input and output items to dedicated storage with a 30-day TTL wheneverstore !== false(apps/gateway/src/responses/tools/response-state.ts), independently of the org's retention level and org kind. DevPass users reach this through Codex CLI, which we document as a DevPass guide — so their payloads are held for up to 30 days on that endpoint. The pages now state this exception, and thatstore: falseopts out.Changes
Fixed the sources rather than patching the bot's prompt:
apps/code/.../legal/privacy) — §1b now says DevPass is metadata only with no setting to enable payload storage, followed by an explicit Responses API exception (30-day dedicated storage,store: falseto opt out, transient in-flight caching). §5 drops the removed retain/metadata choice and the "purge from settings" flow that doesn't exist.apps/code/.../legal/terms) — §5 no longer claims payloads are stored "subject to the retention options available in your account settings"; notes the Responses API exception.features/data-retentiongains a callout that the levels are configurable on standard pay-as-you-go orgs only, and its existing Responses API callout now spells out that the 30-day storage applies to metadata-only orgs including DevPass and chat;learn/policiesgets the same note. This gives the assistant a positive source for both facts, not just the absence of a claim.Both DevPass legal pages got their "Last Updated" dates bumped since the substance changed.
Verification
pnpm formatand a fullpnpm buildpass. No behavior change — the enforcement already exists in the API; this is public copy catching up to it.🤖 Generated with Claude Code
Summary by CodeRabbit