Data Certification API: Give Legal Value to Any Data Your Software Manages
Every piece of software handles data that might one day have to hold up in front of someone who doubts it: contracts, event logs, the output of an AI agent, a recorded consent, a transaction, an internal record. Most days that data just sits there and does its job. Then a dispute lands, or an audit, or a regulator, and the only question that counts is whether you can prove the record existed, exactly like this, at that moment. Synthetic content is everywhere, audits keep tightening, and the EU AI Act has raised the bar on traceability, so the data your application stores is far easier to challenge than it was a few years ago. Building the answer in-house means a seal, a qualified timestamp and a chain of custody you maintain yourself, which is slow work that is easy to get wrong.
So how does a team turn the data it already manages into legally valid, tamper-proof evidence without becoming an expert in eIDAS or in timestamping? A data certification API does exactly that: it gives any record proof of authenticity, integrity and time in hours rather than months. One thing to clear up before we go further: this is about certifying data with legal value through an API. It has nothing to do with professional API credentials such as API 510 or 570, and nothing to do with document verification or identity KYC.
What a data certification API actually does
A data certification API lets software submit any record and receive back proof that it existed, unchanged, at a precise moment: a SHA-256 hash, a qualified timestamp, a digital signature and a chain of custody, returned in a single call. You send data to an endpoint, you get back a portable, court-ready proof package. No new storage layer, no cryptography expertise on your side.
File certification and hash certification
There are two ways to certify, and the difference comes down to where your data lives. File certification takes the actual file, a PDF, an image, a JSON export, and certifies it end to end. Hash certification is for data that should never leave your perimeter: your system computes a SHA-256 hash locally, and only that hash travels to the certification endpoint. The legal weight is the same either way. The second option just keeps the raw content entirely on your side.
Qualified timestamp and digital signature
Each certification carries two cryptographic guarantees. The qualified timestamp fixes the exact moment the data existed, and it is issued by an EU-accredited trust service provider integrated through the API, not minted in-house. The digital signature locks down authenticity and integrity, so any later change to the record breaks the proof. Between them they answer "when" and "is this still the original", which is what a qualified electronic timestamp is built to settle in front of a court.
Technical report, chain of custody and delivery
The output of a call is more than a status code. Every certification produces a PDF technical report with full probative value, plus a complete chain of custody that documents every step the data went through. Delivery is built for real systems: the report lands wherever your stack already lives, through webhook, AWS S3, SharePoint or SFTP, so nobody has to log into a portal to pull evidence by hand.
Does a certification API have legal value?
Yes. Evidence produced through the API is admissible in court, and it rests on recognized legal ground rather than a private promise.
Under the eIDAS Regulation (EU) 910/2014, a qualified timestamp carries a legal presumption of accuracy across all 27 EU member states (Articles 41 and 42): the date and the integrity of the data are presumed correct unless someone proves otherwise. That puts the burden on whoever wants to dispute the record. In the United States, Federal Rules of Evidence 901 and 902 govern how digital records are authenticated, and a documented chain of custody backed by cryptographic proof speaks directly to those requirements. The qualified timestamp here is issued by an EU-accredited qualified trust service provider integrated through the API: TrueScreen integrates that provider's seal, it is not itself a trust service provider. One line worth drawing clearly: this is not document verification or identity KYC. A certification API attests that a piece of data is authentic and unchanged at a moment in time. It does not verify who a person is. Those are different problems, and you can dig into the courtroom side in our guide to the admissibility of digital evidence.
From system data to legal effect: what each field proves
Unlike an electronic signature, which binds a person's identity and intent to a document, a data certification API binds proof of integrity and time to any record, event or log your software produces. Each artifact it returns maps to a specific legal effect: the SHA-256 hash proves the data has not changed, the qualified timestamp proves when it existed, the technical report and chain of custody show how it was handled. The table below pairs the data your software already holds with the legal effect you get under both EU and US frameworks.
| Data your software handles | What the API certifies | Legal effect (EU, eIDAS) | Legal effect (US, FRE) |
|---|---|---|---|
| Contract or signed document | SHA-256 of the bytes plus qualified timestamp | Art. 41: presumption of integrity and of the date | FRE 901(a) authentication; FRE 902(13) for a certified record |
| Event or audit log | Hash plus qualified timestamp per entry | Art. 41 presumption on each entry's existence and time | FRE 902(13)/(14) plus FRE 803(6) business-records exception |
| AI agent output | Hash plus timestamp plus technical report at generation | Traceability evidence aligned with the EU AI Act | FRE 901(b)(9), a process or system producing a result |
| Recorded consent | Hash plus timestamp plus chain of custody | Art. 41 presumption of when consent existed | FRE 901(a) plus 902(14) for a certified digital copy |
| Transaction record | Hash plus qualified timestamp | Art. 41 presumption of integrity at time T | FRE 902(13) certified data copy |
The takeaway for anyone integrating the API: you do not certify everything indiscriminately. Certify the records that, if challenged, would cost you a dispute, a fine or a customer. Consents, critical operation logs and reports that leave your system toward third parties are the obvious candidates.
Qualified timestamp, RFC 3161 and the eIDAS presumption
A qualified timestamp is an electronic timestamp that meets the requirements of Article 42 of the eIDAS Regulation (EU) 910/2014, issued by an accredited qualified trust service provider. Under Article 41, it enjoys the presumption of the accuracy of the date and time it indicates and of the integrity of the data it is bound to. Technically it follows RFC 3161, where a Time Stamping Authority binds a trusted time value to the SHA-256 hash of your data. This is the difference between a real proof of existence and a number your own server wrote.
A data certification API integrates this qualified timestamp so that every record your software handles carries the same presumption, without you running a Time Stamping Authority yourself. It is worth being precise about the roles here: the seal is issued by an accredited third-party QTSP, and TrueScreen integrates it through the API. TrueScreen is not itself a trust service provider. That separation is exactly what makes the proof strong, because the time value comes from an accredited authority, not from the application that generated the data. When you need the deeper legal background, the dedicated guide on qualified electronic timestamps covers it in full.
Who integrates a data certification API
Teams that build software for others and teams that run software internally both reach for a data certification API the moment their data has to defend itself. Four profiles come up again and again.
Software houses and digital agencies
A software house can add certification as a feature that sets it apart, especially for clients in legal, finance, insurance or healthcare, and nobody on the team has to become an eIDAS specialist. The certification API and MCP server sit behind a feature the product already has, and the client walks away with "legally valid output" as a selling point.
System integrators
For a system integrator, certification works better as a horizontal layer than as a one-off feature. Any component in the stack, from the document service to the messaging bus, can call the same endpoint when something needs legal weight, which keeps things consistent across a sprawling architecture.
Companies with in-house or proprietary software
Plenty of organizations run their own management systems, ERPs, CRMs or custom platforms. Organizations use the TrueScreen API to give legal value to logs, consents, contracts and reports without changing how their software stores data. The certified data is internal, and the motive is usually an audit, a compliance obligation, or a dispute that everyone knows is coming.
SaaS vendors
A SaaS vendor can turn certification into a premium tier. Certified reports, immutable logs, proof of consent: customers pay extra for these, and the vendor ships them by routing data through a data certification API instead of building a trust stack from scratch.
Concrete use cases you can ship now
The quickest way to see the value is to look at what you can wire up this sprint. None of this means rebuilding anything. Each one is a call to an endpoint, dropped at the right moment in code you already have.
Certify AI agent outputs via the MCP server. AI agents built on Claude, ChatGPT, Gemini or LangChain can certify their own outputs natively through the TrueScreen MCP server, using the Model Context Protocol with one configuration file and no custom code. With the EU AI Act pushing traceability for higher-risk systems, this is shifting from nice-to-have to requirement. The governance side, from the four levels of certification to AI Act logging, is covered in depth in our work on data certification for AI agents.
Immutable application logs and audit trail. Call the API on every critical event and the result is a tamper-proof audit trail: who did what, and exactly when. Each entry is timestamped and certified, so the log stops being "trust us, our database says so" and becomes evidence.
Consents, onboarding and acceptances in digital flows. When a user accepts terms, finishes onboarding or gives a consent, that moment can be certified as it happens. If the acceptance is ever contested, you hold proof of what was shown and what was agreed, fixed in time.
Certified reports and documents generated by the software. Invoices, appraisals, generated reports: anything your software produces can leave the door already carrying a qualified timestamp and a digital signature, so its date and integrity travel with it.
On-prem hash certification. Hash certification lets you prove a record's integrity without the data leaving your perimeter: the system computes a SHA-256 hash locally and only the hash is certified. In regulated environments where data residency is non-negotiable, this is often the only workable path, and it earns forensic-grade certification without moving a byte of sensitive content.
Automated certified report delivery. Certifications don't have to end in a portal. Through webhook, S3, SharePoint or SFTP, the technical report drops straight into the systems your team already uses, which is what keeps certification from turning into yet another manual step.
Data certification API vs e-signature, blockchain notarization and WORM storage
A data certification API and an electronic signature solve different problems, and the same is true of blockchain notarization and write-once storage. A certification API binds integrity and time to any record. An e-signature binds a person's identity and intent to a document. Blockchain notarization anchors a hash publicly. WORM storage enforces a retention policy. The table makes the trade-offs explicit, including where each one is admissible and where it falls short.
| Property | Data certification API | Electronic signature | Blockchain notarization | WORM / archiving |
|---|---|---|---|---|
| Proves data existed at time T | Yes, qualified timestamp | Only if timestamped | Yes, block time | No, storage policy only |
| Proves integrity (not altered) | Yes, SHA-256 plus timestamp | Yes, via signature | Yes, hash on chain | Partial, write-once |
| Binds an identity or intent | No, binds the data not a signer | Yes, signer identity | No | No |
| eIDAS presumption (Art. 41) | Yes | Art. 25 for signatures | Not automatic | No |
| US court authentication | FRE 901/902 ready | FRE 901(b) | Expert testimony often needed | Records custodian needed |
| Independent offline verify | Yes | Yes | Needs chain access | No |
| Fits automated API workflows | Yes, REST plus MCP | Partial | Partial | Not applicable |
In practice these are complements, not rivals. You certify the data at source with the API, add an electronic seal or digital signature when a person has to sign, and reach for blockchain notarization only when public anchoring is genuinely required. The API is the layer that gives proof of integrity and time to data that is born inside your software.
Producing the proof in court: from API response to admissible exhibit
In US federal courts, authenticity is governed by Federal Rule of Evidence 901(a), which requires the proponent to produce evidence sufficient to support a finding that the item is what it claims to be. A SHA-256 hash captured at source, bound to a qualified timestamp and a documented chain of custody, supplies exactly that foundation. It can reach self-authentication under FRE 902(13) for a certified record of a regularly conducted activity, or FRE 902(14) for a certified data copy, which removes the need to call a witness just to authenticate. For logs, the FRE 803(6) business-records exception fits naturally once each entry is hashed and timestamped. In the EU, the same artifacts trigger the Article 41 eIDAS presumption, so the date and integrity are presumed correct unless the other side disproves them.
What you actually file is concrete: the original file as it was acquired, the SHA-256 hash, the qualified timestamp and the technical report that documents the chain of custody. An opposing expert verifies it the same way anyone would, by recomputing the hash and checking the timestamp, which is why a vague objection rarely survives a hash that matches. For the deeper treatment of how courts authenticate digital material, see the guides on FRE 901 authentication and the digital chain of custody.
Independent verification: how anyone can re-check the proof
The verification of a certified record does not depend on TrueScreen. SHA-256 is a public standard: anyone holding the original file can recompute the hash and compare it to the certified value, with no proprietary tool. The qualified timestamp, built on RFC 3161, is verifiable directly against the Time Stamping Authority of the accredited QTSP that issued it, and the digital signature can be checked the same way. Verification works offline and does not require the certifying service to stay online. That independence is what makes the proof robust: you do not have to trust the vendor, you only have to redo the calculation. TrueScreen applies forensic-grade certification aligned with ISO/IEC 27037, but it is not the authority that issues the seal.
Integration mistakes that destroy legal value
Legal value is fragile with respect to how you integrate the API, not to the technology itself. A handful of recurring mistakes are enough to waste it, and each one has a precise legal consequence:
- Hashing the wrong bytes. If you compute the hash after a transformation, a conversion, a normalization, a re-compression, you certify a version that does not match the original you will have to produce. The hash will not validate against the file in evidence.
- Timestamping too late. Certifying in a nightly batch instead of at the moment of the event means the certified date does not coincide with when the fact actually happened.
- Keeping only the hash. The hash proves integrity, but without the original file there is nothing to compare it against, and the proof becomes unusable.
- Relying on a server clock. A timestamp written by your own machine carries no presumption. Only a qualified timestamp from an accredited authority triggers the eIDAS Article 41 presumption.
- Breaking the chain of custody. Re-uploading, re-saving or moving the data without recording each step leaves a gap that an opposing expert will probe.
Throughput, batching and on-prem hash certification
Certification has to keep up with the system it protects. The API supports batch certification for high-volume pipelines, so you can certify a stream of events without a call per record becoming a bottleneck. When data must never leave your servers, hash certification computes the SHA-256 locally and sends only the hash, which keeps sensitive content on-premise while still earning a qualified timestamp. Delivery through webhook, S3, SharePoint or SFTP means the certified report lands inside your existing systems. The full integration reference lives in the data certification API and MCP server documentation.
How the TrueScreen certification API and MCP server work
TrueScreen is the Data Authenticity Platform that exposes data certification as a REST API and an MCP server, so you can certify data programmatically from a backend service or natively from an AI agent. TrueScreen is the Data Authenticity Platform that certifies any data your software handles through a single REST API call. The REST endpoints cover file certification, hash certification, workflow management, report retrieval and webhook delivery; the MCP server gives AI agents tools to certify files, submit hashes, create workflows and retrieve reports. Whichever path you take, every certification includes a digital signature, a qualified timestamp, a technical report with full probative value, a full chain of custody and secure storage, aligned with eIDAS, ISO/IEC 27037, GDPR and the EU AI Act.
The two integration paths suit different jobs:
| REST API | MCP server | |
|---|---|---|
| Best for | Backend services, existing applications, batch certification | AI agents and assistants that certify their own work |
| How you integrate | Standard REST endpoints with JSON, SDK and code examples | One configuration file, no custom code |
| Typical integration time | Hours, with full documentation and code examples | Minutes |
| Triggers | Any event in your code: a save, a submit, a generated report | The agent decides, or you script it via the Model Context Protocol |
A short example shows how little it takes. A SaaS vendor routes every signed customer consent into a single API call. Each consent comes back as a technical report carrying a qualified timestamp and a SHA-256 hash, delivered by webhook straight into the vendor's S3 bucket. If a consent is ever challenged, the proof is already sitting there, admissible and complete, and the vendor never had to build a timestamping service to get it.
