Your prayer is personal.

When you use Prayer Pew as a guest

In text mode, your prayer plan and finished prayer are saved locally in the browser or app on the device where you made them, so you can return to them. The words you submit are sent securely to our text-generation providers to prepare the plan and prayer.

Personal narration and Fish Audio

When personal narration is prepared, Prayer Pew sends the finished prayer text to Fish Audio, operated by Hanabi AI Inc., to create the spoken audio. A finished prayer contains religious content and may include health or wellbeing details. Fish Audio is an independent third-party service, not part of Prayer Pew. For saved personal narration in the mobile app, this transfer cannot begin until you see the in-app disclosure and choose Agree and play.

On the web, if Fish Audio cannot complete the request, ElevenLabs may receive the same finished prayer text to prepare a backup recording.

Fish Audio's public terms permit it to use Usage Data and Content to develop, train, or improve AI and machine-learning models. Its privacy policy says it may retain Content for as long as its systems need it and may transfer data from the UK or EEA to countries outside that region. Fish Audio may therefore retain the prayer text, use it for model improvement or training, and process it outside your country under its own terms and privacy policy.

On mobile, you can choose Not now and read the prayer without personal narration. Daily Prayer uses public editorial content and does not send your personal prayer text to Fish Audio.

Optional voice conversations

Where Voice is available to you, with Plus or as the free monthly voice conversation for signed-in accounts, choosing Voice starts a live conversation and requests microphone access. Voice uses a separate agreement from saved personal narration. You can switch back to text at any time.

Voice normally runs on OpenAI's live voice service. Your microphone audio travels from your device directly to OpenAI, which listens and speaks the replies. Prayer Pew's server sets up the call but does not receive the audio. The words of the conversation come back to the app as captions and are used to prepare your prayer.

If that service is unavailable, Voice uses a second route. Your microphone audio passes through LiveKit to Deepgram for transcription. Your words and the conversation context go to OpenAI for the AI companion's replies. Reply and prayer text go to Fish Audio for the companion's voice, including its processing described above.

On either route, preparing a finished prayer also uses Prayer Pew's existing text-generation providers. These services receive the content needed to perform their part of the conversation.

To find and fix problems with Voice, we send traces of voice conversations to Pydantic Logfire, in its EU region. These traces can include what you said, the AI's replies and the text used to prepare your prayer, along with timings and error codes. Only Prayer Pew's team can view them, they are kept for up to 30 days, and this content is never sent to our crash reporting, product analytics or hosting logs. In the app, microphone health checks send only counts and fixed codes, never audio or words.

Prayer Pew stores an encrypted checkpoint of committed conversation text, the prayer plan and playback position so you can pause and return, including as a paid guest. That checkpoint expires after 30 minutes without activity. Voice narration files use private storage and are scheduled for deletion after 30 minutes. A finished prayer you save follows the ordinary prayer storage rules. Pausing or ending Voice stops live microphone and speaker use; ending does not by itself delete an already saved prayer.

Audio and cloud copies

Generated prayer audio and word timings are stored in private, environment-specific Cloudflare R2 storage. They are not published on a public asset domain. Signed-in prayer records are encrypted by Prayer Pew before they are stored in the application database.

Take a Pew on Android

Take a Pew is optional. With your consent, Prayer Pew uses Android’s AccessibilityService API to detect when you open an app you chose to pause until you complete a prayer that day, including while Prayer Pew is not on screen. It accesses app package names to recognise your chosen apps, Prayer Pew and your Home screen, and displays a pause screen over chosen apps. Protected apps that prevent overlays remain accessible. It does not read screen content, messages or typed text. When you choose apps, it reads installed app names, identifiers and icons to show the selection list.

App names and your selection are processed only on your device. They are not collected by Prayer Pew or shared with anyone, including analytics and advertising providers. You can decline and continue using Prayer Pew. Disable Take a Pew inside the app or revoke its accessibility permission in Android Settings at any time.

When you sign in or subscribe

Signing in is optional. If you choose Apple, Google, or email sign-in, we keep the verified email address, the name the provider supplies, the provider’s account identifier, and an internal Prayer Pew account identifier so your prayers and access can follow you across devices. The mobile app does not keep a Google profile photo because it has no profile-photo feature.

Apple, Google Play, Stripe, and RevenueCat tell us which plan was purchased and whether access is active. We do not receive or store your full card or payment account details. A keychain-backed installation identifier, push token when notifications are enabled, and the minimum account link needed for purchases and rate limits may also be stored.

When you use Prayer Pew on Alexa

Amazon processes what you say to Alexa and sends Prayer Pew a structured skill request; Prayer Pew does not receive your raw microphone audio. To play the daily prayer for the right day, the skill uses the device-scoped ID and short-lived Alexa API token in that request to ask Amazon for the device's configured time zone. Prayer Pew uses those values only while answering the request and does not log or retain them or the returned time zone. It then gives Alexa the public address of that day's finished narration. The current daily-prayer skill does not require a Prayer Pew account and does not collect a personal prayer request.

If you ask for prayer in a comment on social media

Commenting our keyword on one of our own Instagram posts is a request to have a prayer prepared and sent to you privately. When you do, we read that one comment from Instagram, use your words to write a prayer, and send you a private link to it. We do not store your comment, your username, or your Instagram account details, and the private message we send never repeats or paraphrases what you wrote, because it may appear on a locked device screen. Your words are sent to our text-generation providers to prepare the prayer, in the same way as words typed on this site. The prayer itself is encrypted and kept behind an unguessable private link, and opening that link places a copy in that browser so you can delete it. If a comment suggests someone may be in danger we send information about real help instead, and no prayer is written.

We may also reply publicly, under your comment, to comments on our own posts that do not use the keyword. A public reply never repeats or hints at what you wrote, never carries a link to anyone’s prayer, and is never sent to you privately, because you did not ask us for anything privately. Where a public comment suggests someone may be in danger we post nothing at all, so that no attention is drawn to them, and a person at Prayer Pew is alerted instead.

Sharing

A prayer is private unless you create a sharing link. Anyone who receives an active link can open it without signing in, so share it only with people you trust. You can turn the link off from the original prayer.

Open Pew

Open Pew is public. Anyone may read a request that appears there. You must sign in to post, mark that you prayed, report a request, or block its author, but your account email is never shown on Open Pew. Before posting, you choose either Anonymous or a separate name for Open Pew and confirm that you understand the request may appear publicly.

The request and chosen Open Pew name are sent to OpenAI for automated safety and personal-information screening before anything is published. OpenAI may keep API safety-monitoring data for up to 30 days under its service terms unless our account has a shorter approved retention setting. A request that clearly passes the checks can appear straight away. A request containing private details or an immediate safety concern is not published and the app asks you to edit it or seek appropriate help; nobody is monitoring Open Pew as an emergency service.

Published requests are encrypted in our application database and normally expire from the public Open Pew feed after 30 days. You can remove your own request at any time. Text held only because an automated check was temporarily unavailable is encrypted and deleted after seven days unless it is resolved sooner. We do not keep the raw text of a rejected request. We may keep text-free moderation codes and reports for up to 180 days so we can operate the safeguards, answer an appeal, and prevent repeated abuse.

Product analytics and errors

PostHog and Vercel Web Analytics receive low-cardinality product events such as whether a prayer was played or completed. We do not send prayer text, titles, prayer IDs, share URLs, or Scripture excerpts in product events. We use PostHog session replay to understand problems in the app and website. Text inputs and views containing personal prayers or journal entries are masked. Recordings are retained for 30 days. Console logs and network request contents are not recorded. Internal and automated website visits are excluded from replay. Sentry is used for operational errors and performance; request bodies, account data, cookies, and private route identifiers are scrubbed before reporting. The same scrubbed error reports also go to PostHog: the kind of error and where in our code it happened, never its message. If you deliberately send feedback, the note and optional reply email are stored only in PostHog for our team to review. The form asks you not to include prayer text, private details, or sharing links. The app may also ask a short question once, such as how it is helping or what stopped you choosing Plus. Answers are a rating or one of a fixed set of choices, with no free text, and are sent to PostHog like other product events.

On this website, PostHog also counts visits and page views without cookies: it does not store analytics cookies or a persistent visitor identifier. A browser explicitly marked as an internal test device keeps that marker in local storage. For each page it receives the page address with any prayer, draft, sharing or Scripture identifier replaced by a placeholder and every query parameter removed except advert campaign tags, the domain of the site that linked to the page (not its full address), how long you stayed on the page and how far down it you scrolled, your browser, operating system and device type, and your approximate country. Our hosting provider works out the country from your connection and we pass on only its two-letter code. PostHog uses a random identifier held only in page memory, which resets when the page reloads. Unless you are signed in, no profile of you is built. Onboarding diagnostics include screen and viewport dimensions, device pixel ratio, browser automation signals, language, time zone and touch support. Campaign tags are checked to exclude personal information, and referrers contain only the referring site's origin. We have set PostHog not to store IP addresses. We do this because we have a legitimate interest in knowing how the site is found and used.

On the home page, the pricing page and the start page only, PostHog also records which links and buttons you click, with their visible label, and where on the page you click and move the mouse, so we can see how those pages are used. It does not do this on any other page, and never on a page that shows a prayer.

When you are signed in, we link your product events to an identifier derived from your account. It is not your email address or your account number, and neither can be worked out from it. PostHog keeps the events linked to it together as one pseudonymous analytics profile, filed under that opaque identifier. It lets us count one person across the website and your devices rather than each device separately. We never attach your name, email address or any prayer content to it, and feedback you send through the feedback form is never filed under it. When you are not signed in, your events are not linked to an account.

If you delete your account, we delete the account record that identifier is derived from, and no new events are linked to it once each device that was signed in to the account has been signed out. The pseudonymous analytics profile and the events already linked to it stay in PostHog.

When our service writes a prayer or reads one aloud, we record in PostHog how long each step took, which AI model or voice service did it, how many tokens it used and, for a reading, a rough range for its length. These records contain no prayer, request or Scripture text. When the request came from the app or from a signed-in account, they can be linked to the same app identifier or account identifier as your other product events. During a voice conversation, we record the same kind of record for each reply: how long it took, which AI model gave it and how many tokens it used, never what was said. We also record how long our servers took to answer prayer, reading and payment requests and whether they succeeded.

For a tagged advert, we keep a closed first-party campaign tuple (the source, campaign, creative ID, format and variant) for the current browser tab and copy it to Stripe subscription metadata at checkout. This lets us understand our own funnel without carrying tracking parameters into private prayer URLs. It contains no prayer or account information. It is sent to an advertising network only as part of the advertising measurement described below.

When Stripe verifies that a trial began, that a payment succeeded, or that a subscription renewed, was cancelled or reinstated, changed plan, ended or had a failed payment, we send that product event to PostHog with the plan and, for a payment, its amount and currency. The events of one subscription share an opaque value derived from it, and are joined to the checkout with a random reference made for that browser tab and kept only in its memory. We do not send Stripe customer, subscription or invoice IDs, advertising click IDs, email, account details, or private content with these events, and they do not create a person profile.

In the app, RevenueCat tells us when a subscription trial begins, when it becomes paid, when a subscription renews, is cancelled, reinstated or refunded, changes plan or ends, and when a payment fails. We send each of these to PostHog with the plan, the store and, for payments and refunds, the amount and currency. The events of one subscription share an opaque value derived from it. So that they can be counted alongside the app’s own anonymous events, the app gives RevenueCat its anonymous PostHog identifier. Where RevenueCat holds how the app was installed (for example from one of our Meta adverts) and the numbers Meta gives our own campaign, ad set and advert, we add those to these events too. We do not send store transaction IDs, account details or private content with these events, and they do not create a person profile.

On Android, the app reads Google Play’s install referrer when it is first opened, to record in PostHog whether it was installed from an advert, from our website or directly from the store. When the install came from one of our Meta adverts, the app sends Meta’s encrypted campaign reference from that referrer to our server. The server decodes it and returns only the numbers Meta gives our own campaign, ad set and advert, which the app then records with its analytics. The server does not keep the reference, and it contains no advertising identifier. The app reads the referrer again on later opens only to complete that record: when the first read did not finish, for up to two weeks after an install from one of our Meta adverts until our server has decoded it, and once after an update for an install from the last 90 days that an earlier version of the app recorded without its source.

Advertising measurement

The Meta Pixel and the TikTok Pixel measure visits on a few public pages that carry no prayer, draft, or sharing identifier in their address, and they receive standard browser and device information along with their own measurement cookies when present. Neither ever runs on the pages that hold your plan, your finished prayer, or a shared prayer. The record that a prayer was successfully generated is sent by Meta Conversions API and the TikTok Events API from our server alone, precisely so the private address of your prayer is never handed to either company. If you open checkout, begin a trial, or become a paid subscriber, we may also send that standard event. A first paid invoice includes only its amount and currency; later renewals are not used as new-subscriber conversions.

When you arrive from an advert, the link carries an identifier that tells the network which advert you clicked. We store that identifier in a cookie and copy it to Stripe subscription metadata at checkout, so that the network can match a trial or first payment after the seven-day delay.

In the Prayer Pew app, advert measurement is on. The app tells Meta when it is installed or opened, when a prayer is created, and when you start a trial or subscribe, with the price and currency of a subscription. On Android the app never lets Meta collect your device’s advertising identifier: an install is matched to one of our adverts through Google Play’s install referrer, which describes the advert rather than you, and Meta’s software keeps its own random identifier for the installation. On iPhone, Meta uses the advertising identifier only if you also allow tracking when iOS asks. There is no separate switch in the app. On iPhone, declining when iOS asks withholds the advertising identifier. On Android, if a free trial started in the app becomes a paid subscription, our server tells Meta about that first payment, with its amount and currency. To match it, the app gives RevenueCat the anonymous identifier Meta’s software uses for your install, only while advert measurement runs for the install, and removes it if measurement stops for the install.

On Android, the app can also tell TikTok the same things, once we switch TikTok measurement on: the install and each time the app is opened, that a prayer was created (TikTok receives this as a sign-up), and a trial or subscription starting, with the price and currency of a subscription. TikTok also receives information about your device. It is held to the same consent rules as Meta above, so it never runs where Meta would not, and it never runs on iPhone. TikTok receives no prayer content.

The app does not request Android’s advertising ID permission, so on Android 13 and later no software in the app, Meta’s and TikTok’s included, can read your device’s advertising identifier.

We do not send prayer text, titles, themes, Scripture choices, voice choices, email address, account IDs, prayer IDs, private URLs, or health or religious details. We do not use email or phone matching for advertising. On this website, advert measurement is on, and there is no choice to turn it off. In the app, the one control is iPhone’s own tracking setting.

Your choices

You can remove guest prayers from inside the app or, on the web, by clearing this site’s browser data. You can also revoke any active sharing link or contact us about a signed-in cloud copy. Please do not include the private details of a prayer in a support email.