Data Handling in a PDF Fraud API: What Happens to Uploads

Someone on your team wants to send loan applications, claims or invoices through a PDF tamper-detection API. Before that happens, a vendor-risk questionnaire lands on your desk asking where the files go, who can see them and what is kept. This post answers those questions for HTPBE? in the order a reviewer usually asks them, so you can fill in most of the form without booking a call.

It describes how the service behaves at the time of publication. The live legal pages – the Privacy Policy, the Data Processing Agreement and the subprocessor list – set out the binding terms and commitments. This post describes behavior; it does not add to or change those terms.

Short answer for your questionnaire

If you need one paragraph to paste into a form:

As of October 2026 (the legal pages at htpbe.tech/legal are authoritative): HTPBE? checks a PDF’s structure for evidence that it was edited after it was created; page content is parsed in memory during analysis and no page text is stored. Through the API, the customer submits a URL; HTPBE?’s application server, hosted by the infrastructure provider named on the subprocessor list, fetches the file into memory (10 MB maximum), analyzes it in a worker thread and returns a verdict (intact, modified or inconclusive) with modification marker IDs. No external analysis service receives the file bytes, and the API path does not persist the file bytes to object storage or disk. Stored per check: the verdict, marker IDs, extracted technical metadata, the filename and file size, the submitted URL and, for some files, a hash of the file. Through the API and the dashboard, a result is available only to the account that created it, unless the owner switches on a public share link for that result. Authorized HTPBE? personnel can access check records to operate and support the service. Live API keys are stored as SHA-256 hashes. Files uploaded through the website, unlike API submissions, are stored and may be used to improve the detection algorithm.

Two paths, two answers: API vs website upload

HTPBE? accepts files in two ways, and they are handled differently. Most questionnaire answers depend on which one your team will use.

Website upload. On htpbe.tech, the browser sends the file directly to our object storage (Cloudflare R2) using a short-lived upload link, and the server then analyzes the stored copy. Web-uploaded files are stored, and they may be retained and used to test and improve the detection algorithm. The Privacy Policy describes the conditions.

API. Your system calls the API with a URL pointing to the file. The file is fetched, analyzed and not written to storage. The rest of this post covers the API path unless it says otherwise.

If your files must not be stored by us, integrate through the API, not the website upload. If analysts at your company also drag files into the website by hand, that use falls under the website answer, whatever the integration does.

The API data flow, step by step

1. You submit a URL. Your system calls POST https://api.htpbe.tech/v1/analyze with the URL of the PDF. The request carries no file bytes, only the link.
2. Our server fetches the file into memory. The download is capped at 10 MB. The cap is checked against the declared size and again while the file streams in, so an oversized file is rejected without being read in full.
3. Redirects are not followed. If the URL answers with a 3xx redirect, the request fails. Submit the direct file URL.
4. Analysis runs in a worker on our application server. The file is analyzed in a separate worker thread on the same server that received the request. No external analysis service receives the file bytes.
5. The file bytes are not persisted. The API path does not persist the file bytes to object storage or disk.
6. The result is returned and stored. The response contains a check ID. Calling GET https://api.htpbe.tech/v1/result/{id} returns the verdict and the list of modification marker IDs. The stored record is described in the next section.

We fetch from the URL you give us, so whoever can open that URL can also get the file. Access to the file at its source stays your responsibility.

What is stored per check, and what is not

Two items in that table matter during a review.

Metadata can contain personal data. PDF metadata fields are written by whatever software produced the file. Some generators put a username or a machine name into the creator or producer field. When that happens, the value is part of the extracted metadata we store. Treat the metadata store as potentially containing personal data, not as purely technical.

The submitted URL is stored in full. If you submit signed or presigned links – a common pattern for files in private buckets – the stored URL includes the signature. Use short-lived links, and treat each submitted link as something we hold.

Retention of analysis results and account data is covered by the Privacy Policy. This post does not restate it.

What the analysis reads

HTPBE? analyzes how the file is built – its metadata, its internal structure, any digital signatures and the way its pages are put together, among other properties. These describe how the file was produced and whether it was changed after it was created.

The analysis does not interpret the document’s text or figures: it does not evaluate amounts, totals or names on the page, and it does not check whether what the document says is true. Page content is parsed in memory as part of the structural analysis, but no text from the document’s pages is stored with the result. A verdict says whether the file shows structural signs of being edited after it was created, or, for inconclusive, that a clean result could not be established. It says nothing about whether the issuer, the applicant or the numbers are genuine.

That boundary matters for the questionnaire in two ways. Your data classification for the document content does not change because it passed through a structural check. And an intact verdict should not be read as confirmation that a document is truthful – it means no structural evidence of editing was found. An inconclusive or modified verdict is a reason for further review, not an automatic decision about the person who submitted the file.

Access control

• Results are owner-only. Through the API and the dashboard, a check result can be retrieved only by the account that created it. GET https://api.htpbe.tech/v1/result/{id} called with another account’s key returns 404, the same response as for an ID that does not exist, so the API does not reveal whether a given check exists.
• Staff access. Authorized HTPBE? personnel can access check records to operate and support the service.
• Check IDs are random UUIDs. They are not sequential and cannot be guessed by counting.
• Results are private by default. A public share link for an individual result can be turned on from the dashboard by the account owner. It is off unless someone switches it on, and switching it off revokes access through the link. Anyone holding an active link sees the verdict, the technical metadata shown on the result page and the filename, but not the URL you submitted.

If your policy forbids sharing results outside the organization, the control to watch is the share switch in the dashboard.

API keys

HTPBE? issues two kinds of key.

Live keys (htpbe_live_…) run real analysis and draw on the account’s credits. They are stored as a SHA-256 hash; only the last four characters are kept in clear so you can tell keys apart.

Test keys (htpbe_test_…) return only synthetic, deterministic results for a fixed set of test URLs. They never touch real documents or real results. A test key cannot be pointed at a real file: a URL outside the test set is refused.

The test key is useful in a security review because it lets your engineers build and test the whole integration – request, result retrieval, error handling – before a single real document leaves your system. The decision to send real files can be made after the integration is finished and reviewed.

Transport, logs and errors

• Transport and headers. The site sets HSTS and standard security headers, including a Content Security Policy, frame denial and nosniff.
• Request logs record the IP address and user agent of each request.
• Application logs record document URLs by host only, not the full link.
• Server-side error reports strip request bodies, cookies and query strings before they leave the server.

For encryption at rest, hosting region, transfer mechanisms and breach-notification terms, refer to the legal documents rather than this post: the DPA sets out the processor’s security and notification commitments, and the subprocessor list names each subprocessor and its role.

Deletion and subprocessors

There is no self-serve deletion in the dashboard. Analysis results are deleted on written request to [email protected], and the Privacy Policy commits to processing requests within 30 days, subject to legal obligations to retain certain data. For API checks there is no stored file to delete, so a deletion request covers the stored analysis results.

Subprocessors are listed at /legal/subprocessors, including which apply to the API and which to the website. The DPA covers API customers.

Reviewer FAQ

Do you store our documents? Not if you use the API. The API path fetches the file into memory, analyzes it and does not write it to object storage or disk. Files uploaded through the website are stored and may be used to improve the detection algorithm.

What do you store about each check? The verdict, marker IDs, extracted technical metadata, the filename and file size, the submitted URL in full and, for some files, a hash of the file. See the table above.

Does any third party receive the file? The file is processed in memory on our application server, which runs on infrastructure from the hosting provider named on the subprocessor list. No external analysis service receives the file bytes. Subprocessors for hosting, storage and other functions are listed there.

Who can see results? Among customers, only the account that created them; through the API, other accounts get a 404. Authorized HTPBE? personnel can access check records to operate and support the service. A public share link exists only if the owner switches it on in the dashboard, and switching it off revokes it.

Can we test without sending real documents? Yes. Test keys return synthetic, deterministic results for a fixed set of test URLs and refuse anything else, so the integration can be built end to end with no real files.

How are API keys stored? Live keys are stored as SHA-256 hashes, with only the last four characters kept in clear for display.

How do we get data deleted? Email [email protected]. The Privacy Policy commits to processing requests within 30 days, subject to legal obligations to retain certain data.

Do you hold certifications? This post makes no certification claim. The contractual terms for processing personal data are in the DPA.

Getting started

Build the integration on the HTPBE? API with a test key, get the review signed off, then switch to a live key for real documents. The interactive API reference documents the request and response formats. Create an account to get your keys.