PRIVACY

PRIVACY
POLICY_

This policy explains how Patchflow handles account, repository, billing, support, and operational data while delivering automated code repair attempts.

01Data We Collect

Account data, including your name, email address, authentication provider, and session records.
Repository and repair-job data, including repository URLs, issue descriptions, run IDs, pull request links, status updates, and runner logs needed to deliver the service.
Billing data, including Stripe checkout session IDs, payment intent IDs, refund status, and repair credit records. Full card details are processed by Stripe and are not stored by Patchflow.
Support and contact data, including messages submitted through the contact page and admin notes used to respond to those messages.
Operational telemetry, including request IDs, errors, health-check results, webhook outcomes, and security audit events.

02How We Use Data

To authenticate users, protect accounts, and provide access to the Patchflow console.
To create, queue, run, verify, and deliver automated repair attempts through trusted runner machines and the Patchflow GitHub App.
To process payments, issue credits, handle refunds, reconcile Stripe webhook events, and prevent duplicate credit issuance.
To monitor reliability, investigate errors, detect abuse, and respond to support requests.
To comply with legal, security, accounting, and operational obligations.

03Service Providers

Patchflow uses infrastructure, authentication, payment, repository, email, logging, and monitoring providers to operate the service.
Current providers may include Vercel, Supabase or Postgres hosting, Stripe, GitHub, email delivery services, Sentry, and Axiom.
These providers process data only as needed to deliver, secure, monitor, or support Patchflow.

04Repository Content and Secrets

Patchflow may access repository metadata and code needed for a repair attempt after you authorize repository access.
The Patchflow GitHub App should request only the permissions needed for the repair workflow: repository metadata, contents read and write, and pull requests read and write.
Repository content is used to inspect the reported issue, prepare a minimal patch, create or update a repair branch, and open a pull request for your review.
Do not submit production secrets, credentials, regulated data, private keys, or data you are not permitted to share.
Runner machines may execute code from submitted repositories. Treat connected repositories as trusted only when you have authority to process them through Patchflow.

05AI Use and Model Training

Patchflow does not require customers to provide an OpenAI API key to Patchflow for repair execution.
Private repository content submitted to Patchflow is not sold and is not used by Patchflow to train Patchflow-owned foundation models.
Repository code, issue descriptions, runner notes, and pull request context may be processed by the System workflow only as needed to deliver the requested repair attempt.
If Patchflow adds a new hosted AI provider path that changes how repository content is processed, Patchflow should update this policy before using that path for customer repositories.

06Storage, Caching, and Logs

Patchflow stores compact service records such as repository URL, repository full name, job description, status history, runner logs, pull request URL, billing records, contact messages, and audit events.
Temporary runner folders may contain checked-out source code while a repair is active. The runner workflow is designed to remove local source artifacts after completion, failure, or cleanup.
Patchflow operational logging is designed to avoid full repository source, full diffs, access tokens, cookies, private keys, secret values, and full webhook payloads.
Monitoring providers may receive structured event metadata such as route names, error names, request IDs, job IDs, and health-check results, but should not be used as storage for repository source code.

07Access Controls and Revocation

Repository access is controlled through GitHub App installation settings. You can remove Patchflow from a repository or organization in GitHub.
Patchflow account access is controlled through the supported sign-in providers and database-backed sessions.
Runner API access is protected by a shared runner token configured outside the public client application.
Revoking GitHub App access may stop Patchflow from cloning, updating branches, or delivering pull requests for queued or in-progress jobs.

08Security Incidents

No third-party repository processing workflow can eliminate all risk. Patchflow uses scoped access, audit records, structured logging, and cleanup workflows to reduce exposure.
If Patchflow becomes aware of unauthorized access, accidental disclosure, or a security incident affecting customer repository content, Patchflow will investigate and take reasonable containment steps.
When required by applicable law or when the incident materially affects a user, Patchflow will use available account or support contact information to notify affected users.
You should immediately revoke the GitHub App installation and contact support if you believe a repository was connected by mistake or a credential was exposed.

09Retention and Deletion

Patchflow keeps account, billing, audit, and job records as long as needed to operate the service, resolve disputes, enforce terms, and meet legal or accounting requirements.
Operational logs may be retained by monitoring and logging providers according to their configured retention periods.
You may request account or support-message deletion by contacting support. Some records may be retained when required for security, fraud prevention, legal, or accounting reasons.

10Your Choices

You can stop using Patchflow, disconnect repository access through GitHub, and request support with account or data questions.
You can contact Patchflow to request access, correction, deletion, or export of personal data where applicable law provides those rights.
Patchflow may need to verify your identity before acting on privacy requests.