Privacy

Privacy and account data.

Account, usage, and collections

Ezra stores normalized email/account identity, credential hashes and prefixes, device/scopes and credential state, monthly per-account usage and the Free account’s last admitted UTC day, and billing/entitlement records needed for access. Requesting account sign-in can create or reuse an account before email verification or successful delivery.

Collections store Bible references, along with names, descriptions and tags you supply, their owner, visibility and timestamps. These saved fields can contain personal or spiritual information. Private collections are owner-only. Unlisted collections can be retrieved by ID; public collections can appear in discovery. Previously shared or retrieved copies cannot be recalled.

Tool arguments are processed to perform your requested operation. The implemented database accounting stores call counts, not raw questions, prompts, conversation transcripts or Scripture-request text as request logs. Intentionally saved collection content is separate from this accounting. Platform and provider logging may process additional request information; this is not a guarantee that nothing is recorded elsewhere.

Separate aggregate statistics contain only UTC day, a fixed tool-name bucket and account tier with call counts. They contain no references, topics, text, translation IDs, account IDs, email or network/session identifiers, and are not joined back to personal quota records. A count represents events, not distinct people. Daily WEB and art do not contribute to these charged-call statistics.

OAuth, when enabled

OAuth stores registered clients, browser-bound authorization/consent state, scoped grants and hashed token metadata for an existing account. Permissions separate Scripture calls from collection reads and creation; they do not authorize account, key or billing administration.

OAuth uses necessary short-lived first-party Secure, HttpOnly cookies to bind sign-in and consent to your browser. This differs from the account page's in-memory session token.

Security rate counters use pseudonymous hashes derived from network addresses and email identifiers. They protect sign-in and authorization; they are personal security records, not anonymous query analytics.

Local client storage

The CLI saves account/API credentials in a private local config file. The bridge uses a configured or saved key to authenticate requests. The web account page holds its session token in memory; it does not save it to browser storage.

Account magic-link and checkout-session parameters are removed from the address bar before asynchronous verification. The required proof/session is still sent to Ezra for verification; account inputs remain available for a retry.

Analytics, feedback and service providers

Website analytics and optional feedback collection are disabled on these pages: they do not load Datafast or the analytics helper, and no automated outbound feedback solicitation is enabled. Personal quota and security records remain necessary service accounting, separately described above.

Cloudflare hosts the service, D1 data, assets and, where enabled, SQLite-backed OAuth Durable Object state. Stripe processes payment/billing information, including customer/account links and refund requests. Klaviyo handles sign-in and lifecycle email/events when configured, including the sign-in code or magic link and required account properties. Support email is configured to forward through Cloudflare Email Routing to Gmail. These configured paths do not establish delivery success or provider retention settings.

When a paid user selects an API.Bible edition, Ezra sends the selected provider translation ID and canonical Bible passage to API.Bible and returns its original text and copyright/attribution. The server API key is not returned. Manual usage-reporting mode also sends the provider-issued usage token and configured device, session and logged-user identifiers to API.Bible’s FUMS service; these provider identifiers are separate from Ezra’s aggregate statistics. Their mapping and provider requirements need explicit operational configuration, and are not described as anonymous. API.Bible retention and reporting exemptions are not established by local tests.

Retention and recovery

General account, usage, collection, credential and billing/audit D1 records have no implemented automatic general deletion period. Sign-in codes and OAuth credentials have validity limits; expiration or consumption stops their use but does not mean every stored record is physically erased. OAuth has expiration checks and bounded cleanup, without a physical-erasure deadline.

Paid D1 recovery history can retain restorable data for 30 days. SQLite-backed Durable Object recovery, where used, can restore SQL and KV state within 30 days. These are recovery windows, not universal provider-erasure deadlines. Workers Logs retain 7 days on paid plans if enabled; this version's Worker log configuration is disabled. Other Cloudflare operational records and Stripe, Klaviyo and Gmail retention/deletion remain unverified.

Private requests and safe reports

Send questions or requests about access, correction, export, revocation or deletion to support@ezramcp.com. Account actions require safe ownership verification. This version has no general self-service account deletion or export; no delivery, response or completion deadline is promised. Subscription cancellation is not account erasure.

Use the support guide for sanitized technical reports. Never send keys, tokens or email codes, or publish private account/collection data in GitHub issues.