Privacy

Local invoice checks stay in your browser. Hosted checks send invoice data to Attestwire for processing in memory. This page explains the data used for accounts, payments, optional validation records, registration lookups and website analytics.

Invoice data sent to the API

This is the part that matters most if you are integrating, so it goes first.

An invoice you send to api.attestwire.com is processed in memory and never stored. It is parsed, validated or generated, and answered; when the response is written the payload is gone. There is no database of invoices, no cache, no queue and no backup holding one. Responses carry Cache-Control: no-store. Payloads are never used to train anything: the engine is deterministic TypeScript, and we send payloads to no third party.

Validation records, only if you ask for one

If you add ?record=true to a POST /v1/validate call, we store a validation record of that check: the verdict, each finding (its rule, severity and message), the engine and rule-set versions, the time, and a SHA-256 fingerprint of the document. The document itself is not stored. A finding’s message can quote a value from the invoice, such as a VAT identifier, a name or an email address, so a record can contain those values.

Anyone who has the record’s link can read it; the link contains a 128-bit random identifier, and that is the only access control, so share it only with the people it is for. Records are deleted automatically 365 days after they are made. To delete one sooner, email hello@attestwire.com with its link.

Alongside each record, and never shown with it, we keep a salted hash that ties it to the key that made it, so abuse can be traced.

Live registration lookups are separate. VAT checks send the VAT number to VIES, the EU service for checking VAT numbers, and Peppol checks send the participant identifier to the public lookup service run by OpenPeppol, the association that operates the Peppol e-invoicing network. They do not send the invoice itself to those services.

We do not log invoice payloads in normal operation. Errors are logged as the error class name and the route, with no stack trace. The one exception is our Paddle webhook handler, which logs a stack trace on failure and never carries an invoice payload. What we keep for an API account is on the security page, listed in full: nothing about the documents themselves.

The full detail, including where processing physically happens and who our subprocessors are, is on the security page. If you need a GDPR Article 28 processor agreement, one is written: the data processing addendum.

AI agents using the MCP server

The MCP server at api.attestwire.com/mcp is how AI assistants such as Claude, Cursor and similar tools reach the API. So we can see what those assistants are trying to do and where the service falls short, the server records a short usage entry for each connection and each tool call. An entry never contains invoice content, and never the name, VAT number, company search or other text an assistant sends with a call.

Each entry holds only these:

• Which tool was called, or the name of a tool that does not exist, which tells us what people want that we have not built.
• Which assistant software connected, and its version, as it names itself (for example claude-code/2.1).
• How it went: whether the call succeeded and how long it took.
• A short summary from a fixed list of fields: the invoice profile and syntax, two-letter country codes, the three-digit document type code, the rule identifiers an invoice failed (such as BR-DE-15), and our own error codes. Anything that does not have the expected shape is recorded as other.
• A connection identifier: a random number the server issues when an assistant connects, so the calls of one connection can be read in order. It is not linked to you, your key or your device, and nothing is stored against it.
• The first eight characters of your API key’s hash, if the call carried a key. Not the key, and not enough to recover it. This is the same short form our error logs already use.

No IP address is recorded in an entry. To stop one connection flooding the feedback tool described below, the server counts that tool’s calls per API key, or per IP address when there is no key. The count lives in the server’s memory, is never written down, and is gone within the hour.

The feedback tool

The server also offers assistants a send_feedback tool. An assistant may call it to tell us, in its own words, what you were trying to do when the service could not help, or when a result looked wrong or confusing. We ask assistants not to include invoice contents, names or identifiers.

Before anything is stored we also remove email addresses, API keys, IBANs, VAT numbers and long numbers from the text. The text is capped at 1,000 characters. Feedback is anonymous, so we cannot reply to it; if you want an answer, email hello@attestwire.com.

Usage entries and feedback are stored in Cloudflare Workers Analytics Engine, in the same Cloudflare account that runs the API, and are deleted automatically after three months. They reach no other company. We read them ourselves, as daily totals and by reading the feedback text directly, to decide what to fix and build next.

The lawful basis is our legitimate interest in understanding how the service is used and improving it (GDPR Art. 6(1)(f)). If you want an entry removed, tell us roughly when and from which assistant, and we will find and delete what we can.

What we collect, and where

Three places on our properties take an email address:

• The rule-change alert form on this site (on the homepage and on the changelog), which posts to /api/alerts.
• The update list on the French E-Invoicing Checker (check.attestwire.com), a free tool we build.
• The downtime alert form on the VIES monitor (vies.attestwire.com), which posts to its own /api/alerts.

This site used to carry a fourth: a "need more than 100 documents a month" box posting to /api/waitlist. The hosted API is self-serve now, so the box is gone. That endpoint still answers (it is the same store the alert form writes to, under the name it was published under), and the paragraph below on getting removed applies to those records as it always did.

The rule-change alerts and the update list store the same three things, and only these:

Email address

Lowercased, and used as the storage key, so a second submission updates nothing rather than creating a duplicate.

Timestamp

ISO 8601, of your first submission. Later submissions do not overwrite it.

Source

A short label such as home, so we know which form you used.

The VIES alert form stores the same email address and timestamp, plus one extra field: the member state you asked to be told about, or nothing if you asked about all of them. That is the only difference between the lists.

One more form is not a list at all. The "create my key" box on the homepage sends your address straight to api.attestwire.com to issue an API key, the same thing POST /v1/keys does from your terminal, and the address is not stored on attestwire.com at all.

What the API keeps is an account record: the address, the tier, and the SHA-256 hash of the key. We do not email you because you created a key. That record is described on the security page.

The email forms do not record your IP address, user agent, referrer, name, company, or anything you did not type into the box. There is no account, password or profile.

One place IP addresses are used: the hosted API applies abuse-prevention rate limiting keyed on the calling IP address, today on the key-issuing endpoint, so that one caller cannot mint unlimited free keys, and, in memory only, on the MCP feedback tool (described above). Those counters reset daily or sooner, are not a record of you, and are not joined to an account or to anything else.

Why

To reply to you about the thing you asked about, and nothing else. That is the entire purpose; we run no newsletter, drip sequence or marketing automation. Under the GDPR the lawful basis is your consent (Art. 6(1)(a)), given by submitting the form. You can withdraw it at any time and we delete the record.

Cookies and analytics

No cookies. No local storage. Two things measure anything on this site, both named here: Cloudflare Web Analytics for page views, described in this section, and our own event counters, described in the section below it. There is one further exception on the checkout page, which is described below.

We run Cloudflare Web Analytics on this site, and on the free tools, so we can see which pages get read and which rule pages people land on.

What that means in practice, stated so you can check it against Cloudflare's own documentation rather than taking our word for it:

• It is cookieless. It sets no cookie and writes nothing to local storage, which is why there is no consent banner on this site.
• It uses no client-side state and no fingerprint to follow you between visits, so it does not build a profile of you and cannot recognise you as a returning visitor.
• It does no cross-site tracking. The measurement is confined to our own hostnames; it is not an advertising network and the data is not shared with one or sold.
• What it reports to us is aggregate: page paths, referrers, country, browser and device class, and page-load timing. We do not receive a list of visitors, and there is nothing in it we could use to identify you.

It is a third-party script, and you should know that. Every page here loads one file from outside this domain, https://static.cloudflareinsights.com/beacon.min.js, which is the beacon that reports those page views. Apart from the two payment pages described below, it is the only cross-origin request the site makes; there are no external fonts, images, stylesheets, pixels, tag managers, or advertising or social scripts.

Loading it means Cloudflare receives the technical details of that request, including your IP address, in the same way it already does as the host serving this page. Block it in your browser and every page here works as before.

Cloudflare processes that data as our infrastructure provider, under its own terms and privacy policy. We describe what the product does; we do not warrant Cloudflare's conduct, and we cannot audit it for you. If you need the vendor's own commitments, read them at cloudflare.com/privacypolicy.

We may change or drop the analytics provider. If we do, this page says so and carries a new date. That notice is here, on this page, and it is the notice you get.

Our own event counters

Cloudflare Web Analytics reports page views. It cannot tell us whether anyone pressed a button, so three pages here also count a small number of named events: the homepage, /playground and /pricing. This is first-party. Nothing is sent to a third party and no vendor is involved.

An event is a name, and the name is the whole record. The name comes from a fixed list written into our Worker, it is sent when you press one of a few specific buttons or when a check on /playground finishes, and it is stored as a count. What is recorded is that somebody, once, did a thing with that name.

• No document data. An invoice you check on /playground is processed in your browser and is not uploaded. No part of it and nothing derived from it is in any event, not the verdict, not the size, not the syntax. The event that page sends is a button press, identical whether the box holds an invoice or nothing at all, and there is no field in the record that could hold more.
• No identifier. There is no cookie, session id, device id, fingerprint or random number. Two events from you are indistinguishable from two events from two people, so the counts cannot be assembled into a visit, a journey or a profile.
• No IP address. The endpoint that receives an event does not read the connecting address, does not store it and does not rate limit on it. Cloudflare routes the request as it routes every other request to this site; we take nothing from it.
• No URL, referrer, user agent, screen or clock. None of it is read and none of it is sent. We do not even stamp our own time: the record carries the arrival time Cloudflare's own store writes.
• Nothing is written to your browser. No cookie and no storage of any kind, which is why the sentence above still says "no cookies" without an asterisk.
• Do Not Track and Global Privacy Control are honoured. If your browser sends either signal, nothing is sent at all. Blocking the script has the same effect, and every page works as before.

The counters are Cloudflare Workers Analytics Engine, a store inside the same account that already serves this page, so the events reach no company that was not already handling the request. The full list of names and the code that writes them are in the site's Worker; to see what a button sends, open the network panel and press it. The request is one short line of JSON.

The two pages that are different: /pay and /fix

Two pages on this site load a second third-party script, and both of them are pages you only use to pay us. /pay is where a hosted-API upgrade is paid for, and /fix is where the one-time Invoice Fix Report is bought. Each loads https://cdn.paddle.com/paddle/v2/paddle.js so that Paddle, our payment provider and merchant of record, can open its own payment window on our domain.

No other page here loads it, and it is not analytics.

What that means for you, stated the same way as the beacon above. /pay is noindex and does nothing without a checkout link, so you cannot arrive there by browsing. /fix is an ordinary readable page and you can arrive there by browsing, so the script loads with it, before you have decided anything.

That is the cost of putting the payment window on the page that describes what it buys. We collect nothing on either: /pay reads the transaction id out of the URL and hands it to Paddle, /fix hands Paddle a price id when you press the button, and neither stores anything anywhere. Paddle's own script may set cookies or browser storage on those pages to run its checkout and its fraud checks.

That is Paddle's, under Paddle's privacy policy, and it is why the sentence at the top of the analytics section says "no cookies" about this site rather than about every script that can run on it. Your card details go to Paddle and never to us.

/fix/claim, the page that shows the key after a Fix Report is paid for, loads no payment script at all. It sends the transaction id to api.attestwire.com, shows you the key that comes back, and writes nothing to your browser: no storage or cookie, and no copy of the key anywhere but the screen.

Who else touches the data

We do not sell, rent, share or trade email addresses, and we send them to no marketing, CRM or advertising service.

Two processors, both named here. Cloudflare is our infrastructure provider: these sites run on Cloudflare Workers, the email records live in Cloudflare Workers KV, and the analytics described above are Cloudflare's product. Like any web host, Cloudflare processes the technical details of your request, including your IP address, in order to serve and protect the site.

We do not retain those logs as a record of you, and we do not join them to anything. Paddle handles payment for the hosted API as our merchant of record, and never receives an invoice payload; card details are entered on Paddle's checkout, not ours, and the billing email, address and any tax ID you give at checkout are held by Paddle so it can charge the right tax and issue your invoice.

Both act as our infrastructure and payment providers under their own terms. We describe what they do for us and we choose them carefully, but we do not warrant their conduct and we cannot audit them on your behalf. The full list, with what each one touches, is the subprocessor table on the security page.

How long we keep it

Until you ask us to remove it, or until the list has served its purpose and we delete the whole store, whichever comes first.

Getting removed, or getting a copy

Email hello@attestwire.com from the address you signed up with, or just tell us which address to look for. We delete it and confirm. There is no form or login to go through.

The GDPR also gives you the right to access the data we hold, correct it, object to the processing, receive it in a portable form, and lodge a complaint with your national supervisory authority. Ask at the same address; we answer within 30 days, usually the same week.

Contact

Attestwire: hello@attestwire.com. That address reaches a person, and it is the right one for privacy requests, security reports and everything else.

Changes, and what this page is

This page describes how the site and the service work today. It is a description of current practice, not a contract: the binding commitments are in the terms and, where you have one in place, the data processing addendum, and where the DPA says something different from this page, the DPA governs.

Practices change: we may add, replace or drop a provider, including the analytics one. When that happens this page is updated and re-dated, and that is the notice. DPA customers additionally get 30 days' notice before a new subprocessor starts processing their data.

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