# 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.

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](mailto:security@pdfblocks.com).

**Prefer a document?** Download the [PDF Blocks Security Whitepaper
(PDF)](/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](/docs/trust/dpa), 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](/docs/api/regions-and-data-residency) documentation.

The HIPAA-aligned endpoint is for workflows involving protected health
information, under a signed Business Associate Agreement. See [HIPAA](/docs/trust/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](/docs/trust/dpa) 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](/docs/trust/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](mailto: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](mailto: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](/.well-known/security.txt).