Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.paywalls.ai/llms.txt

Use this file to discover all available pages before exploring further.

This page summarizes how Paywalls handles authentication, data, and payments, and what you should do to keep your integration secure.

Authentication & key management

  • Keep your paywall API key server‑side only (server, edge function, or backend‑for‑frontend).
  • Use environment variables or a secret manager; never hard‑code secrets in code or frontends.
  • Rotate keys if you suspect exposure; remove old keys and redeploy.
  • Prefer restricted provider keys (e.g., Stripe Restricted Key) with the least scopes needed.
  • Use Idempotency-Key for non‑idempotent POSTs (e.g., manual charges, deposits) to prevent duplicates.
See also:

Data handling & privacy

  • Pseudonymous users: prefer stable, pseudonymous user IDs; avoid sending PII where not required.
  • Data minimization: do not include secrets or PII in prompts, system instructions, or metadata fields.
  • Operational metadata: ledgers and logs store request identifiers (e.g., user, requestId, model id) for billing, support, and audit.
  • Prompts & outputs: your app controls what content is sent to providers; treat prompt data as potentially sensitive.
  • Encryption in transit: all APIs require HTTPS (TLS 1.2+).
See Privacy for full privacy policy and data subject rights.

Payments & PCI scope

  • Default mode: you collect funds into app‑scoped balances via your own rails (e.g., Stripe). Card data remains within Stripe flows; Paywalls does not handle raw card numbers.
  • Shared mode: Paywalls hosts top‑ups; checkout and card handling occur with our payment providers. Your earnings accrue on usage and are available for withdrawal per policy.
  • Taxes/invoicing: your app remains responsible for its own ToS, privacy, and tax obligations to end users.
See:

Network & transport security

  • All API endpoints are served over HTTPS; reject plain HTTP.

Data retention & deletion

  • We never store prompt or output contents; only request metadata (e.g., usage data, model/version, timestamps, pseudonymous user/request identifiers) is retained.
  • Ledger entries are retained for billing and audit purposes.
  • Operational logs are retained for troubleshooting and reliability.
  • Configurable retention and regional data hosting are on the roadmap. Contact us for current defaults and options.
  • For data deletion requests, contact support with relevant identifiers (user, ledger ids, request ids) to assist.

Compliance posture

  • We design systems and processes to support common regulatory requirements (e.g., GDPR/CCPA principles of data minimization, access, and deletion on request).
  • Data Processing Addendum (DPA) and subprocessors list are available on request.
  • Formal certifications (e.g., SOC 2) are on the roadmap; reach out for current status.

Vulnerability & incident response

  • Responsible disclosure: report potential vulnerabilities to legal@paywalls.ai. Provide details and reproduction steps.
  • We assess, prioritize, and remediate security issues based on severity.
  • In the event of a security incident affecting your data, we will notify impacted customers consistent with legal and contractual obligations.

Backups & disaster recovery

  • Regular backups of critical data with encrypted storage.
  • Service restoration and continuity procedures are maintained;

Your responsibilities

  • Keep secrets server‑side; never expose paywall, stripe or provider keys to browsers or untrusted clients.
  • Send a user with every billable request; avoid PII where possible.
  • Verify webhooks, log request identifiers, and make side‑effects idempotent.
  • Follow your local laws and platform policies (privacy, taxes, consumer protection).
Questions or requests (e.g., DPA, retention details, incident reports): legal@paywalls.ai