Launching today
DocImprint
MCP-native document proofs agents can verify
8 followers
MCP-native document proofs agents can verify
8 followers
DocImprint is MCP-native verifiable document memory for AI agents. One POST /v1/extract turns PDFs and URLs into tamper-evident evidence bundles — SHA-256 manifests, Merkle citations, free offline verify. Pay per call with x402 USDC on Base, or use API keys. Built for legal, finance, and compliance agents that must prove what they read — beyond logs.The verifiable document layer for AI agents — tamper-evident evidence bundles, cryptographic proofs, MCP-native, and x402 USDC pay-per-call on Base.
Tried extracting a PDF and the Merkle citations came back instantly, super clean. Love that I can verify offline without hitting the API again.
@sulunhats29843 Thanks! That's exactly the design goal — the manifest ships with everything needed to re-verify (hashes, Merkle root, signature) so you're trusting math, not our server, after the fact.
Curious what you're building — happy to dig in if there's a specific extraction/citation use case you're working on.
The cryptographic proof angle is genuinely clever for compliance use cases. One thing that would help me as a user: add a lightweight web UI or CLI tool that lets you paste a citation hash and instantly see the original source and timestamp without needing to write code. Right now the verification flow assumes API access, which is friction for non-engineers who still need to audit the bundles.
@zeynepakj0 Good catch. We do have a no-code verifier (docimprint.com/tools/verify-bundle) — paste a bundle_id, get signature status and timestamps back, no code required. But you're right it works on bundle_id, not a raw citation hash, and it still calls our API rather than verifying purely offline.
That's a real gap, not just a nice-to-have — appreciate you being specific about it.
Love the Merkle citation angle, super relevant for our compliance work. One idea: add a simple SDK wrapper for Python and TypeScript so agents can call /v1/extract without hand-rolling the HTTP client and signature headers. Right now wiring it into our internal stack took longer than it should have, and a thin official SDK would make adoption way smoother.
@lkerabanogfxgp Thanks Ilker — glad the Merkle citation piece lands for compliance work specifically, that's exactly the use case we built it for.
Good timing: we already ship official SDKs that handle the HTTP client + signature headers for you, so /v1/extract should be a few lines, not hand-rolled auth:
TypeScript: https://www.npmjs.com/package/docimprint .
Python: https://pypi.org/project/docimprint/
Source: https://github.com/sawftware-apps/docimprint-sdk
If you hit friction wiring it into your stack even with the SDK, I'd genuinely like to hear where — that's exactly the kind of thing that should be invisible.
posted a PDF and the merkle bundle came back in under a second, the offline verify actually worked from a cold machine which i did not expect.
@melis4234740829 Nice — that's the whole point of shipping the manifest self-contained: hashes, Merkle proof, and signature are all local to the bundle itself, so verification never depends on server state or a live session. The only external thing you need is the public signing key, which is why cold-machine verify "just works" instead of secretly still calling home.
What'd you end up testing it on — scanned doc or clean text PDF? Curious which path you hit.