Privacy Policy

When you create an account, we receive identity data such as your email and authentication subject from Clerk. We store subscription state, device and Live Activity push tokens, paired-host records, and credentials needed to authenticate requests. For provider webhooks, Chirp stores a one-way token hash, non-secret prefix, label, provider scope, expiry, and usage timestamps; the raw token is returned once and is not stored. Event payload fields are processed to validate, render, route, and troubleshoot the Live Activity or notification you requested.

Your email is used for account identification and support. Device tokens are used to deliver push notifications and Live Activity updates that you or your integrations initiate. Device-paired host credentials authenticate interactive tools; broader API credentials may authenticate reviewed headless integrations. Provider-bound webhook credentials authenticate only their selected inbound bridge. Permission-bridge requests process the minimum host, tool, sanitized context, expiry, and decision data needed to bind one response to one blocked request.

We do not sell your personal information. Service providers involved in operating Chirp may receive the data necessary for their role: Clerk for authentication, Apple Push Notification service and/or Expo for device delivery, Google FCM when Android delivery is enabled, RevenueCat for subscription state, and our hosting/database providers for the API. Each provider processes data under its own terms and privacy policy.

The default history setting is ephemeral. In that mode, Chirp skips diagnostic notification-log writes. Active Live Activity state must still be stored while an activity is running so later updates and end events can reach the same device. Ended activity state is removed on lifecycle completion on a best-effort basis, with a scheduled retention sweep as a backstop.

If you’d like a short history window for debugging, your dashboard lets you opt up to 7 or 30 days. That setting governs notification logs, ended Live Activity instances, activity snapshots, Webhook Inspector events, and OpenRouter usage events. Zero-day Webhook Inspector and OpenRouter accounts skip event persistence at ingestion; the retention sweep also removes existing rows in every covered history table.

If you enable Webhook Inspector, Chirp stores the received method, path, query, content type, a body truncated to 16 KB, timestamps, and forwarding outcome for that inspector. If you enable OpenRouter usage tracking, Chirp stores provider/model, token counts, reported cost, optional tag, and timestamp. Those feature-event rows follow the selected 0/7/30-day history window. Account identity, entitlement, device tokens, paired hosts, active activity state, delivery attempts, approval audit/security records, and billing-event hashes follow separate operational lifecycles. Provider-webhook credential hashes, labels, scopes, expiry, revocation, and usage metadata are retained as operational/security records until account deletion; raw webhook tokens are not retained after one-time issuance.

You may request account deletion from the iPhone app. Chirp first requests deletion of its RevenueCat customer record and corresponding Clerk identity, then commits deletion of the backend account row and dependent service data only after those provider requests succeed. If an external provider rejects the request, Chirp reports failure instead of falsely claiming that local deletion completed. In the rare case both provider deletions succeed but the local database deletion does not commit, Chirp reports that operator completion is required. This flow remains a production launch test gate. Legal, fraud-prevention, security, authentication, and store providers may retain records under their own policies.

You may request access, correction, export, or deletion of your Chirp data. Account deletion is available in-app under Settings › Manage › Delete Account. To request a data export or raise a privacy concern, contact support@chirpapp.dev.

Chirp credentials are bearer secrets: anyone who obtains one may act with its scope until it is revoked or expires. Interactive setup uses code-verified host pairing so a reusable account key is not placed in a prompt or URL. A provider console that cannot set headers may use a URL containing a lower-authority token bound to that bridge; the URL remains a bearer secret. Production clients use HTTPS, and credentials can be revoked. We do not claim that every provider payload is end-to-end encrypted from your tool to the Lock Screen.

Chirp is a developer tool and is not intended for children under 13. We do not knowingly collect information from children.

We may update this policy from time to time. Material changes will be communicated via the app or email. Continued use after changes constitutes acceptance.

For privacy inquiries, email support@chirpapp.dev.