I work on OnePassApps, so this is our own product, and every number below was read from our live API and our live legal page in one session on 4 November 2026.
Our privacy copy is careful. It tells you what we keep, where we keep it, and it gives you a way to ask. In most places it deliberately does not print the retention period itself - "Contact us for the current backup period and the status of a deletion request."
The API is more direct. One public route, no account and no session, answers with our privacy configuration - including five retention numbers - in plain JSON. This is what it returns, and how it lines up with the words on the terms page.
The route
GET https://api.onepassapps.com/api/auth/config
That is the whole request: no key, no cookie, no session. Measured from outside the browser on 4 November 2026:
- HTTP 200
- content-type: application/json
- 371 bytes
The body, verbatim, on one line:
{"ok":true,"data":{"publicSignupEnabled":true,"checkoutOpen":false,"privacy":{"controllerName":"OnePassApps","controllerAddress":null,"supportContact":"info@onepassapps.com","retention":{"accountBackupDays":35,"usageCostTelemetryDays":90,"rateLimitEventDays":30,"signalDeskSharedMetadataHours":48,"generatedAudioMinutes":30}}},"meta":{"requestId":"req_..."}}
Two details are worth knowing before you build on it.
The JSON lives on the API host, not the front-end host. The same path on app.onepassapps.com answers HTTP 404 with text/html - the app's 404 page, not JSON. A fetch from the browser to app.onepassapps.com/api/auth/config will not hand you this object.
And its siblings do not exist. /api/auth, /api/auth/session and /api/auth/user on the API host all answer 404 with the same envelope every other missing route uses:
{"ok":false,"error":{"code":"NOT_FOUND","message":"That route does not exist."},"meta":{"requestId":"req_..."}}
The five retention numbers
| Key | Value | What the key names |
|---|---|---|
| accountBackupDays | 35 | restricted backup copies of an account |
| usageCostTelemetryDays | 90 | usage and cost telemetry |
| rateLimitEventDays | 30 | rate-limit events |
| signalDeskSharedMetadataHours | 48 | shared metadata for the product our API calls signaldesk |
| generatedAudioMinutes | 30 | generated audio |
The keys are the API's own names - the response carries no descriptions, no units beyond the key names and no comment on what "starts counting from". I read the route three times in a row: the five values did not move between reads. The only field that changed each time was meta.requestId, a fresh id per call.
Our API has one other public runtime route, /api/runtime, and it lists the product keys the runtime knows about: signaldesk and movie-tracker, both set to mode inherit. The signalDesk key in the retention block is named for the first of those.
What the terms page says next to them
This is the part worth reading carefully, because the two documents do not say the same thing.
The terms page publishes retention periods of its own, in prose:
- "Membership consent and billing-notice evidence is kept for the membership duration and at least three years from acceptance or one year after termination, whichever is later."
- "Active guest requests are normally removed after 180 days without a customer or public support interaction."
- "Resolved requests are normally removed after 365 days and closed requests after 180 days."
None of the five numbers appears in the rendered terms text: I checked for "35 days", "90 days", "48 hours" and "30 minutes" on both pages.
And the terms are explicit that the backup period is the one they will not print there:
"Deletion removes data from the active account. Restricted backup copies can remain until the configured backup retention period expires; deletion controls must also be reapplied if a backup is restored. Contact us for the current backup period and the status of a deletion request."
So the number exists, the API publishes it, and the legal page routes you to a person to get it. Both are defensible - a period can change between the copy and the request - but if you want the machine-readable answer, /api/auth/config is where it is, and it was the only place that answered without a form.
Two flags ride along
The same response carries two booleans that are not about privacy at all:
- publicSignupEnabled: true
- checkoutOpen: false
The second one matches what the plans page says in plain words: "New payments paused".
And the privacy block names the controller - "OnePassApps" - with a null controllerAddress, and the support contact info@onepassapps.com, which is the same address the terms give for privacy requests.
What I did not do
I did not create an account, I did not start a subscription and I did not ask for a deletion. This is one read of one public route plus one read of our own legal page, on one build, signed out and from outside the browser. Retention periods can change, so read the live route and the live terms before you rely on either.
The live terms and privacy page:
The app guides, which spell out what each app needs:
I work on OnePassApps, so this is our own service and our own copy, measured today rather than described from memory.
