PDF Blocks Security
How the PDF Blocks document-processing API protects your data: stateless in-memory processing, no document retention, encryption in transit, and defense-in-depth network isolation.
Last updated 27 July 2026
This page describes the security of the PDF Blocks document-processing API — the service that receives, transforms, and returns your PDF documents. That is where your data is handled, so it is the focus here. It is a stateless service that stores nothing, and it runs separately from our account and billing systems, which never receive your documents. This page is written for the security and procurement teams who evaluate us; if you need a control not covered here, contact security@pdfblocks.com.
Prefer a document? Download the PDF Blocks Security Whitepaper (PDF) — a shareable summary of everything on this page.
Two commitments that define the API
Most of what makes PDF Blocks safe to adopt comes down to two structural facts about how the API works:
- We never store your documents. The API processes each file in memory and returns the result in the same response. Documents are never written to a database or durable storage. A large upload may be briefly buffered to a temporary file for the duration of a single request, and it is deleted the moment the request completes.
- Our pipeline is deterministic, with no LLMs. Every action is document manipulation implemented in code: the same document and the same parameters always produce the same output. No large language model reads your documents, the pipeline calls no third-party AI service, and nothing you send us is used to train or fine-tune a model.
How your documents are handled
When you send a document to the API, it is received over TLS, processed in memory, and streamed back in the response. Nothing about the document’s content is retained. For each request we record only metadata — an API-key digest, the action requested, input and output byte counts, the response status, and a timestamp — which we use for billing, security, and abuse prevention. The processing we perform on your behalf is governed by our Data Processing Addendum, available to business customers.
Because documents are never persisted, there is no document data to export, delete, or produce a certificate of destruction for — the guarantee is structural rather than a policy we have to enforce.
AI and machine learning
PDF Blocks is not an AI product. Actions such as merge, split, rotate, watermark, stamp, and password protection are deterministic transformations written in code, and they are the whole of what the API does with your file. No large language model reads your documents, and no document content is sent to a third-party AI service.
A few operations have to work on what a page looks like rather than on its structure. Reading a barcode is the clearest example: locating the symbol on the page and decoding it may use visual computing. That is image analysis, not a language model, and it runs inside the same isolated environment with no outbound internet access as everything else. Either way the rule is the same: we do not train machine-learning models on your documents, and we never use their contents for anything beyond the operation you requested.
Encryption
- In transit. All connections are encrypted with TLS. We enforce a modern TLS 1.3 / 1.2 policy, and plain-HTTP requests are permanently redirected to HTTPS. Traffic between the API’s internal components is also TLS-encrypted.
- At rest. The API keeps no durable storage, so there is nothing to encrypt at rest by design. A large upload may be briefly buffered to a temporary file for the duration of a single request; that file is deleted the moment the request completes and is never retained.
Authenticating to the API
Requests are authenticated with an API key, which identifies your account so we can authenticate the request and meter usage for billing. We store each key only as a SHA-256 digest with a short display prefix; the full key is shown once, at creation, and is never recoverable from us afterward. Keys can be revoked at any time, and revocations are retained as an audit trail. Keys are scoped to a plan, which governs the regions, document sizes, and volumes they may use.
An API key is a usage credential, not a door to your data. It tells us which account a request belongs to so we can authorize it and count it toward your plan, and that is all it does. There is no endpoint that lists, downloads, or replays documents you have already processed, because we never stored them in the first place. Someone who steals a key can spend your quota, which is why keys can be revoked instantly, but they cannot reach a single one of your documents. The response to each request is the only copy, and it is yours.
Infrastructure
The API runs on Amazon Web Services and Microsoft Azure, defined as infrastructure-as-code and deployed through a reviewed, automated pipeline. Key properties:
- Network isolation. Document processing runs in isolated private networks with no outbound internet access, so it cannot exfiltrate data even in principle.
- Edge protection. The API is protected by a web application firewall with rate limiting.
- Hardened, ephemeral hosts. Compute runs on current, patched base images; instance disks are encrypted and are destroyed when an instance is retired.
- Physical security of the underlying data centers is inherited from AWS and Microsoft Azure, which maintain SOC 2, ISO 27001, and PCI DSS attestations for their facilities.
Regions and data residency
You choose where your documents are processed by addressing a regional endpoint; the request is processed entirely within that jurisdiction and nowhere else. The API is available in the following regions, each stateless and running the full action catalog:
| Region | Endpoint |
|---|---|
| Global (latency-routed) | api.pdfblocks.com |
| United States | us.api.pdfblocks.com |
| United States (HIPAA-aligned) | hipaa.api.pdfblocks.com |
| European Union | eu.api.pdfblocks.com |
| United Kingdom | uk.api.pdfblocks.com |
| Canada | ca.api.pdfblocks.com |
| Australia | au.api.pdfblocks.com |
| Japan | jp.api.pdfblocks.com |
| India | in.api.pdfblocks.com |
| Brazil | br.api.pdfblocks.com |
Because processing is stateless, data residency comes down to a single decision — which host you send the request to. Details are in our Regions & data residency documentation.
The HIPAA-aligned endpoint is for workflows involving protected health information, under a signed Business Associate Agreement. See HIPAA.
Application and development security
- Every change is version-controlled, peer-reviewed, and merged through continuous integration that runs automated unit, integration, and contract tests before code can ship.
- Each commit is scanned with automated security tooling — static analysis of the application code and dependency-vulnerability auditing — and dependency updates are proposed automatically and reviewed.
- Deployments authenticate with short-lived, federated credentials (no long-lived cloud keys) and require an explicit human approval step to reach production.
- Releases are health-checked and roll back automatically if a new version fails its readiness self-test.
Vulnerability management and incident response
Vulnerabilities are identified continuously — dependency scanning, static analysis, provider advisories, and external reports — triaged by severity, and remediated on defined timelines, with critical issues addressed within days. We handle security incidents under a documented plan with defined severities and response steps, and we notify affected customers of confirmed or suspected customer-impacting incidents without undue delay, consistent with our Data Processing Addendum and applicable law.
Availability and resilience
- In every region, the API runs with redundant capacity across multiple availability zones, behind health-checked load balancers, with automatic replacement of unhealthy capacity.
- Deployments use rolling updates with automatic rollback, so a failed release does not take the service down.
- Because the API is stateless, recovery is a matter of healthy capacity — there is no document data to restore — and a disruption in one region does not affect the others.
Logging and monitoring
We log only request metadata — the action, byte counts, an API-key digest, status, and timestamp — and never the contents of your documents. Logs redact credentials and tokens. Infrastructure metrics and alarms watch error rates, latency, and host health so we can detect and respond to problems quickly.
How our controls map to common frameworks
The PDF Blocks API is engineered to align with the criteria that formal frameworks such as SOC 2 and ISO 27001 assess. The table below summarizes how our controls map to the SOC 2 Trust Services Criteria; we are glad to walk a reviewer through the evidence behind any of them.
| Trust Services Criterion | How the PDF Blocks API addresses it |
|---|---|
| Security (common criteria) | TLS 1.3 in transit; web application firewall and rate limiting; isolated private networks with no outbound access; hashed API keys; least-privilege access; automated vulnerability scanning. |
| Availability | Redundant capacity across availability zones, health checks, a multi-region API, and rolling deploys with automatic rollback. |
| Confidentiality | Documents processed in memory and never stored; encryption in transit; strict network segmentation; confidentiality obligations on staff and subprocessors. |
| Processing Integrity | Deterministic document operations; peer review, continuous integration, and contract tests that gate every release; change management with automatic health-checked rollout. |
| Privacy | No document retention; documents never shared with any subprocessor; no use of customer data to train AI; data residency selectable per region. |
Subprocessors
Document processing runs on Amazon Web Services and Microsoft Azure. The contents of your documents are not shared with any subprocessor — they are processed within our own infrastructure, in the region you address. The full list of subprocessors, with each provider’s purpose and location, is maintained on our Subprocessors page.
Documentation available on request
Customers and prospects on the Business plan can request, under a mutual NDA, our internal security policies (Information Security, Access Control, Cryptography, Data Protection & Retention, Vulnerability Management, Secure Development, Incident Response, and Business Continuity) and a completed security questionnaire. Email security@pdfblocks.com to start.
Reporting a vulnerability
If you believe you have found a security vulnerability in PDF Blocks, please report it to security@pdfblocks.com. We welcome coordinated disclosure, will acknowledge your report, and ask that you give us a reasonable opportunity to remediate before any public disclosure. Our machine-readable contact details are published at /.well-known/security.txt.