Security

1. Principles

Security work on RelayPDF is aimed at a small set of non-negotiables.

No internet service is perfectly secure. You still have to protect dashboard access, API keys, webhook secrets, and any passwords you send to unlock or protect a PDF.

• TLS for every public API and dashboard connection
• API keys hashed at rest; the full secret is shown once at creation
• No logging of HTML, uploaded files, or PDF passwords
• Generated files requested as a download URL exist for 24 hours, then are deleted
• Private-network and metadata URL fetches are rejected (SSRF controls)
• Failed jobs are never billed and must not increment operations
• Card numbers never touch RelayPDF servers — Stripe is the payment processor
• Customer document content is not used to train public models

2. Infrastructure

RelayPDF does not run its own data centers. The product is split across a small set of providers, each doing a specific job.

Those providers publish their own physical-security, SOC, ISO, and PCI materials. If you need a vendor packet for procurement, email support@relaypdf.com.

3. Data in transit

api.relaypdf.com and relaypdf.com require HTTPS. Uploads, JSON bodies, and file downloads use TLS. We do not offer a plaintext API.

• Authorization is an HTTP Bearer API key (`Authorization: Bearer pdf_live_…`). Keys in query strings are rejected.
• Dashboard sessions use Clerk cookies over HTTPS.
• Webhook deliveries to your HTTPS endpoint include `RelayPDF-Signature` (`t=<unix>,v1=<hmac>`). Verify HMAC-SHA256 of `{t}.{raw_body}` with the endpoint secret. Node `verifyWebhook` and Python `verify_webhook` implement that check.
• Per-job `callbackUrl` is HTTPS only and is unsigned. Use dashboard webhooks when you need signatures.

4. Data at rest

What we store, and for how long, depends on the object.

R2 and Postgres use provider-managed encryption at rest. Download URLs are unguessable object ids (`/v1/files/:id`), not sequential integers. GET /v1/files/:id does not require an API key because the id is the capability; treat the URL as a secret for 24 hours.

5. How a job is processed

Example: POST /v1/pdf with HTML and `response: "url"`.

Convert jobs follow the same billing and logging rules, but the bytes go to the document container (LibreOffice or wkhtmltopdf) instead of Chromium. Raster uses pdftoppm in that container. If the container is unreachable, you get `503 convert_unavailable` and are not billed.

• The Worker authenticates the hashed API key, applies rate limits, and validates the JSON schema. Invalid bodies never reach Chromium and are not billed.
• Private, loopback, link-local, and cloud-metadata URLs are rejected (`url_not_allowed`) if the job would fetch a URL.
• HTML is sent to Cloudflare Browser Rendering. We do not write that HTML into application logs.
• On success the PDF is stored in R2 with a 24-hour TTL. The JSON response contains `id`, `url`, `filename`, `sizeBytes`, and `expiresAt`.
• A generation_logs row records source (`html`), status, latency, and size — not the document.
• The wallet is debited only after a successful result. A 4xx/5xx leaves the balance unchanged.
• If you registered a dashboard webhook, we POST a signed `job.completed` (or `job.failed`) event. We do not put file bytes in that event.

6. API keys and dashboard access

Write endpoints require a live key. Keys are secrets.

• Created in /dashboard/keys or via `relaypdf login` / `relaypdf setup` (browser Approve). Coding agents must not ask you to paste a key.
• The full `pdf_live_…` value is shown once. After that the UI shows a prefix only.
• The database stores a hash, not the secret. A leaked hash is not enough to call the API.
• Revoke from the dashboard (or admin, for operators). The old secret returns `401 unauthorized`.
• Local `pdf_dev_` keys do not work on production.
• GET /v1/account returns plan, rate tier, and wallet millicents. It does not return email, Stripe ids, or keys, and it is not billed.

7. Logging and support access

Dashboard → Logs shows the last generations: id, source, status, latency. That is metadata, not a document archive.

• We do not log HTML, Markdown, template HTML, uploaded file bytes, or PDF passwords.
• Error JSON uses `error.code` and a short `error.message`. It must not echo your payload.
• Wallet ledger rows show reason, signed amount, running balance, and source on usage — not card numbers or files.
• Operator admin (`/admin`, allowlisted) can see prefixes, wallet, and the same metadata logs — not document bodies.
• There is no “strict logging” add-on because bodies are not stored in logs in the default mode.

8. Files, passwords, and URL fetches

Controls that apply to the bytes you send and receive.

{
  "url": "https://api.relaypdf.com/v1/files/pdf_...",
  "userPassword": "secret",
  "filename": "locked.pdf"
}

9. Application controls

The Worker validates every write with shared Zod schemas before work starts.

• JSON-only write bodies. Oversized uploads return `413 payload_too_large` (15 MB per file).
• Rate limits: 5 writes / 10 seconds burst per key; 20/min on trial; 60/min after a Stripe top-up or when auto-reload is enabled; 60 file downloads / min / IP. GET /health is not rate limited.
• Account suspend (`403 account_suspended`) is operator-driven.
• CORS allows Authorization and Content-Type so the playground and first-party dashboard can call the API; your key still has to be valid.

10. Payments

RelayPDF uses a prepaid wallet. Stripe Checkout and the billing portal handle cards. We store Stripe customer references and millicent ledger rows, not PAN/CVC.

Stripe is a PCI DSS Level 1 service. Auto-reload charges the saved method when balance drops below your threshold; a failed reload does not invent a document charge.

11. Subprocessors and international transfers

Strategic Products LLC (Florida, USA) operates RelayPDF. Processing is in the United States and on Cloudflare’s global network. EEA/UK/Swiss personal data in your payloads is a transfer you initiate; we rely on Standard Contractual Clauses with subprocessors, as described in the DPA.

The live subprocessor table for customer content is in the DPA. Email support@relaypdf.com if you need a signed copy.

12. Incidents, deletion, and contact

Report suspected vulnerabilities or a personal-data incident to security@relaypdf.com. Do not attach live API keys, webhook secrets, or large files to the ticket.

• We will acknowledge security reports and tell you what we know that you need in order to protect your users, within the limits of an ongoing investigation.
• Close the account from the dashboard or by emailing support@relaypdf.com. Keys are revoked. Customer content is deleted or anonymized as described in the Privacy Policy, except records we must keep for billing, tax, or law.
• Legal: /privacy, /terms, /dpa. Entity: Strategic Products LLC, d/b/a RelayPDF, 1583 Hansen Street, Sarasota, FL 34231.