PP-TSA issues signed digital timestamps over the hash of a file or record. Your original data never leaves your hands, yet you keep evidence that it existed by the recorded time and that anything presented later is the same data.
The original stays in your custody.
Your own system derives a fingerprint locally.
PP-TSA signs the hash together with the recorded time.
Keep the returned token alongside the data and verify whenever needed.
Integration: REST API for new in-house implementations, RFC 3161 for PDF, electronic signature and archival tools that already support it. Both are available on the same account.
Only a hash is sent. PP-TSA cannot see the content, and you keep the data itself.
A signed timestamp ties the fingerprint to a recorded time, so the moment is not just an entry in your own log.
The signature, the certificate chain and the public ledger entry can be checked again years later.
Copying, substituting and overwriting leave almost no trace. When an audit, a dispute or a handover requires an explanation, you need the exact data bound to a time you did not set yourself.
Modification dates, screenshots and logs you administer yourself can be changed together with the data they describe.
In a dispute or a handover, the question is whether what is presented now is what existed then. Filenames and sizes do not answer it.
A proof that cannot be re-checked after the issuing system changes is not much use when it is finally needed.
Each row states one claim, and what it does not cover. Click a row to open the detail.
The hash of the data is signed together with the time recorded by PP-TSA. The claim is about existence by that time, not about who authored the content or whether it is correct.
Backdating, and arguments that rest only on file dates or screenshots that the holder could have altered.
Recomputing the hash of the presented data and comparing it with the timestamped hash shows whether it is the same data, bit for bit.
Silent substitution or overwriting, and disputes over which version was the one at issue.
The token carries PP-TSA's signature and its certificate chain. Verification confirms the issuer and that the chain was valid, and reports revocation state separately.
Forged or altered tokens, and treating an unverifiable token as if it had been checked.
Issued tokens are added to a public ledger of fingerprints. A signed checkpoint shows that a token is included and that the history up to it is consistent. The original file is never published.
Quiet removal or reordering of issued timestamps, and reliance on the issuer's word alone.
Your system computes the fingerprint and sends only that. Confidential documents, personal data and source code can be timestamped without leaving your environment.
Exposure of confidential material through the act of obtaining evidence.
REST API for new implementations, RFC 3161 for tools that already support it. Requests carry a hash, an algorithm, a random nonce and an idempotency key, so retries never double-issue.
Manual, forgotten timestamping, and duplicate issues from unclear retries.
A timestamp establishes that the data existed by the recorded time and that what is presented now is the same data. It does not establish who created the content, whether the content is correct, or who holds rights to it. Ledger inclusion may be pending at the moment of issue; pending, overdue and unknown are never reported as complete.
Register with an email address and an environment for your organisation is created on the spot.
Pick one to match your monthly issuing volume. You can change it later.
The key is shown once at issue. Record it the way your organisation handles secrets.
Hash locally, call over HTTPS, then store the token with the data and verify independently.
Compute the hash in your own system and POST it to /v1/timestamps as JSON. A Base64 token and its metadata come back — suited to backend services, web services and CI pipelines.
Send a TimeStampReq to /tsr and receive a TimeStampResp. Choose this when PDF, electronic signature or archival products already speak RFC 3161.
Not an industry question — it applies wherever "it existed then" or "this is the same file" may have to be shown.
Fix the final version of an agreement, a quotation or an invoice, so a later dispute turns on the data itself rather than on whose copy is newer.
Timestamp results, drawings and design records at the point they are produced, without disclosing their content to anyone.
Bind published builds and their manifests to a time, so what shipped can be distinguished from what was rebuilt later.
Keep photographs, measurements and inspection logs verifiable, so authenticity does not depend on the administering system.
Whether evidence is trusted depends on what is collected and how results are reported. Both are constrained from the start.
The service takes a fingerprint, an algorithm and request metadata. There is no path by which original content reaches PP-TSA.
An API key is shown once at issue and is never displayed again. Lost keys are replaced by issuing a new one and revoking the old.
Signature, certificate chain, timestamp state, ledger inclusion and revocation are reported separately. Pending and unknown are never presented as verified.
Every request carries an idempotency key. A retry after an unclear result reuses the stored request bytes and key rather than issuing again.
No. Your system computes a hash locally and only that hash is sent. Confidential documents and personal data stay in your environment.
Signing up with an email address and choosing a plan. There is no sales process and no prior screening.
Yes, over RFC 3161. For new in-house work the REST API is usually simpler; both are available on the same account.
No. It establishes that the data existed by the recorded time and that what is presented later is the same data. Authorship, correctness and rights are separate matters.
Reuse the stored request bytes and the same idempotency key. The original result is returned rather than a second timestamp being issued.