Data processing addendum

This agreement is for customers who need GDPR Article 28 terms for personal data processed through the hosted API. It explains each party’s responsibilities and the processing safeguards. To arrange the agreement, follow the steps below.

1. Parties and scope

This addendum is between you (the Customer) and Ben Harborne, sole proprietor, Woodside, California, USA, trading as Attestwire (the Processor). It forms part of the terms of service and applies wherever we process personal data on your behalf under the GDPR (Regulation (EU) 2016/679) or the UK GDPR. Terms used here have the meanings the GDPR gives them. Where this addendum and the terms conflict on data protection, this addendum wins.

2. Roles

You are the controller. You decide which invoices to send and why. We are the processor for the personal data contained in invoice payloads you submit to the API — typically names, addresses, contact details and identifiers of your customers and your own staff, appearing as fields of a document.

These payloads are processed transiently and are not stored. A payload exists in memory for the duration of the request and is gone when the response is written. There is no database of invoices, no cache, and no backup containing one — which shapes several clauses below, particularly deletion and breach.

Separately, we are a controller in our own right for account data: the email address you signed up with, your tier, the billing fields on your key record, and per-key request counts.

That account data includes an IP address. POST /v1/keys is open to anyone, so we count key requests per IP address per UTC day and refuse the sixth. The counter is named after the address and holds a count for one day. No other route records one, and none is attached to a validation, to a key record or to a log line.

This was not stated here before 12 August 2026; the omission was ours, and the behaviour is unchanged. The security page describes it in full.

The same controller role applies to visits to our marketing website, where we run cookieless Cloudflare Web Analytics. None of this touches invoice payloads, and none of it is processing on your behalf, so it is described in the privacy notice rather than here. No analytics runs on the API.

3. Subject matter, duration, nature and purpose

Subject matter

Validation and generation of electronic invoices against EN 16931 and its national restrictions.

Duration

For each payload, the duration of the API request. For a validation record you ask for (?record=true), 365 days from its creation or until you ask us to delete it, whichever is sooner; a record holds the findings and a fingerprint of the document, not the document, but a finding can quote a value from it. For the relationship, as long as you have an account.

Nature and purpose

Automated technical conformance checking and document generation. No profiling, no automated decision-making with legal effect, no analysis of the content for our own purposes.

Types of personal data

Whatever your invoices contain: names, business and postal addresses, email addresses, telephone numbers, VAT and other identifiers, bank details, line-item descriptions, amounts.

Categories of data subject

Your customers and suppliers, and the individuals named in the documents (for example an accounts-payable contact).

Special categories

None expected. The API is not designed for special-category data (Art. 9) and you should not send it.

4. Our obligations (Article 28(3))

• (a) Documented instructions. We process personal data only on your documented instructions. Your API calls are those instructions; this addendum and the terms are the rest of them. That includes transfers to a third country — see section 6. If we are required by EU or member-state law to process otherwise, we will tell you first unless that law forbids it.
• (b) Confidentiality. Anyone authorised to process the data is bound to confidentiality. Today that is one person, the operator, who is bound by this addendum directly.
• (c) Security. We apply appropriate technical and organisational measures under Article 32 — summarised in section 7.
• (d) Subprocessors. You give general authorisation for the subprocessors in section 5, on the notice terms stated there. Each is bound by data protection terms no less protective than these. We remain liable to you for their performance.
• (e) Data subject rights. We assist you, so far as possible, with requests under Chapter III. In practice the assistance we can give is limited by design: because payloads are not stored, we cannot locate, export, correct or delete an invoice after the request completes — there is nothing to act on. Requests we do receive directly we forward to you rather than answering.
• (f) Assistance with Articles 32–36. We assist with security, breach notification, impact assessments and prior consultation, taking into account the nature of the processing and the information available to us. We notify you without undue delay, and in any case within 48 hours, of becoming aware of a personal data breach affecting your data, with what we know at the time.
• (g) Deletion or return. On termination we delete the account data we hold, or return it, at your choice, and delete any validation records you created. Invoice payloads need no deletion step because none is retained.
• (h) Information and audit. We make available the information needed to demonstrate compliance with Article 28 and submit to audits or inspections by you or an auditor you mandate. In practice: ask at hello@attestwire.com and you get straight answers and the architectural detail behind the security page. We hold no SOC 2 or ISO 27001 report to hand you instead — see what we do not have. An on-site audit of a serverless deployment with no premises is of limited use; we will not obstruct one, and we ask for reasonable notice and that it not be more than once a year absent a specific concern.

We will tell you if, in our opinion, an instruction of yours infringes the GDPR (Art. 28(3), final paragraph).

5. Subprocessors

You authorise these subprocessors:

Change notice: 30 days. Before a new subprocessor starts processing your data we notify the data protection contact on your account. If you reasonably object on data protection grounds within those 30 days, tell us and we will either find another way or you may terminate the affected service and get a pro-rata refund of anything prepaid. There is no penalty for objecting.

6. International transfers

We are established in the United States, and Cloudflare Workers executes requests at the point of presence nearest the caller, so personal data may be processed outside the EEA and the UK.

For those transfers the parties rely on the Standard Contractual Clauses approved by Commission Implementing Decision (EU) 2021/914, Module Two (controller to processor), which are incorporated into this addendum by reference and completed as follows: Clause 7 (docking) applies; Clause 9(a) Option 2, general written authorisation, with 30 days' notice as in section 5; Clause 11 optional redress body does not apply; Clause 17 governing law and Clause 18 forum are those of Ireland; Annex I parties and processing description are sections 1 to 3 above; Annex II technical and organisational measures is section 7; Annex III subprocessors is section 5.

For UK transfers, the UK International Data Transfer Addendum (version B1.0) applies to those Clauses; for Switzerland, references to the GDPR are read as references to the FADP and the supervisory authority as the FDPIC.

Section 11 of the terms (California law and venue) governs the commercial relationship. It does not displace the governing law of the Standard Contractual Clauses, which stands as stated above.

On residency: EU-origin requests are normally processed inside the EU, but we do not contractually guarantee it today, and we will not write a promise here that the infrastructure does not enforce. See where processing happens.

7. Technical and organisational measures

The measures under Article 32 are described in full on the security page, which forms Annex II of the Standard Contractual Clauses. In summary:

• Invoice payloads processed in memory only, never written to storage; responses marked Cache-Control: no-store.
• Invoice payloads not logged, ever. Errors are logged as the error class name and the route, with no stack trace and no field value. The one exception is the Paddle webhook handler, which logs a stack trace on failure and never carries an invoice payload.
• TLS in transit throughout; the API is HTTPS-only.
• API keys stored as SHA-256 hashes only; shown once, never recoverable.
• No servers to administer — serverless execution on Cloudflare Workers. State is limited to Workers KV (the key record: email, tier, timestamps, past-due flag, subscription status and Paddle identifiers; the email index; Paddle event receipts; rotation pointers and retirement markers) and Durable Objects (request counts per key, and a daily key-request count per IP address).
• IP addresses are used only to rate limit POST /v1/keys. The counter is named after the address and holds a count for one UTC day. No other route records one, and none is attached to a validation, to a key record or to a log line.
• Administrative access limited to the operator and protected by multi-factor authentication.
• Payment data handled entirely by Paddle, our merchant of record; card details never reach our systems.
• No error-tracking SaaS, CRM or advertising vendors anywhere in the stack. The only analytics is Cloudflare's own, on the marketing pages: cookieless Cloudflare Web Analytics, plus first-party event counters that store a name from a closed list and no identifier. Neither runs on the API and neither sees personal data you send us as controller.

Measures may improve over time; they will not be reduced below what is described here without notice.

8. Liability and term

This addendum starts when we confirm it by email and runs until you stop using the service. The liability cap in section 9 of the terms applies to this addendum too, except where the Standard Contractual Clauses provide otherwise for data subject claims — those Clauses prevail over anything inconsistent here.

Last updated 22 September 2026. If this page changes materially we will say so here rather than silently swapping it.