Developer integration

Build with Evidentia

Use the Evidentia API from your backend to generate and verify Proof records for AI decisions.

Request access Open dashboard Verify Evidentia View examples

5-minute quickstart

Create a proof from your backend, then share verification evidence.

Create an Open Beta workspace and generate an API key.
Store the API key server-side only; never expose it in frontend code.
Send proof metadata with Authorization: Bearer API_KEY and an Idempotency-Key.
Poll proof status, then store proof_id and verification_url in your own system.
Share the public verification link or export package only for proofs intentionally made public.

Start Open Beta Inspect a proof SDKs, CLI, Postman

Why Evidentia exists

Logs explain. Evidence proves.

AI decisions are becoming operational. Evidentia gives teams a way to preserve verifiable evidence while keeping raw prompts, outputs, and sensitive context in their own systems.

Recommended architecture

Server-side REST API

[ Customer Frontend ]
        ↓
[ Customer Backend / Server ]
        ↓ Authorization: Bearer EVIDENTIA_API_KEY
[ Evidentia API ]
        ↓
[ Proof generation / Verification URL ]

Your frontend calls your backend. Your backend holds the Evidentia API key and sends only the proof metadata Evidentia needs.

Evidentia API must be called from your backend server.

Do not call Evidentia directly from browsers, mobile apps, or frontend code.

Current integration

Use REST today. SDKs will follow.

Current integration is server-side REST. Node.js, Python, and framework-specific SDKs will come after the API surface stabilizes.

REST is the most stable path for early integrations while the API continues to harden.

Proof scope

What Evidentia can help prove

That a proof record was created.
That submitted proof data has not been altered.
That a timestamp, signature, or anchor is consistent.
That a public verification page matches the proof metadata.

Verification limits

What Evidentia does not prove

That the underlying AI decision was correct.
That customer-provided data was truthful.
That legal admissibility is guaranteed.
That regulatory compliance is guaranteed.
That an audit will be passed.

How it works

From backend event to verifiable proof

Your backend sends proof metadata.
Evidentia hashes and signs the proof.
The proof is stored with verification metadata.
The proof may be anchored to a blockchain network.
Anyone with the public URL can verify the proof.

Call Evidentia from your backend, avoid sending raw AI data by default, and use public verification without exposing raw prompts or outputs.

Private beta trust scope

Current signing infrastructure

Current private beta uses platform-managed signing infrastructure intended for technical evaluation. It validates the verification flow, not production-grade key custody.

Proof integrity.
Consistency of proof metadata.
Tamper detection.
Reproducibility of verification.

Future production infrastructure

Production trust infrastructure is planned

Persistent production-grade key management, hardware-backed signing, external key attestation, and independently auditable signing infrastructure are planned for future production environments.

Persistent signing identities.
KMS/HSM-backed signing.
Externally auditable trust infrastructure.
Key rotation policies.
Independent attestation.

Steps

Integration flow

Create your workspace
API key generated
Store the API key in your backend environment, Secret Manager, or CI/CD secrets.
Send Proof requests from your backend to Evidentia.
Check proof status
Store proof_id, verification_url, public_proof_api_url, and status in your database.
Share a public verification URL only after a proof is intentionally published.

Security

API key handling

Evidentia API must be called from your backend server.
Never expose API keys in frontend code, mobile apps, GitHub, browser storage, or logs.
API keys belong only in server-side environments such as .env files, secret managers, or CI/CD secrets.

Data minimization

Send proof metadata, not raw data

Do not send raw prompts, raw outputs, personal data, or confidential business data unless you explicitly choose to.
During private beta, send hashes, summaries, and metadata whenever possible.

Idempotency

Use the header as the source of truth

The Idempotency-Key header is required. Use the same value for the same AI decision to prevent duplicate proof requests.

Use the same Idempotency-Key for the same AI decision to prevent duplicate proof requests.

Client logs

Keep your application logs

Operational debugging
Internal records
Analytics
Business workflow history

Evidentia Proof

Add verifiable proof

Tamper-evident proof
Third-party verification
Audit and dispute evidence
Proof that a decision happened

Reference the same decision_id in your client log and Evidentia Proof so internal records and external proof stay safely linked.

Client storage

Store the IDs you will need later

After a Proof is requested and completed, store these values in your own system.

decision_id
idempotency_key
job_id
proof_id
verification_url
public_proof_api_url
status
created_at
related_internal_log_id

Proof request

POST /api/proof/request

Request proof. Check proof status. Store proof_id and verification_url.

curl -X POST "$EVIDENTIA_API_BASE_URL/api/proof/request" \
  -H "Authorization: Bearer $EVIDENTIA_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: decision_123" \
  -d '{
    "event_type": "ai_decision",
    "event": {
      "prompt": "sha256:<input_hash>",
      "output_summary": "sha256:<output_hash>",
      "context": {
        "decision_id": "decision_123",
        "model": "gpt-4.1",
        "environment": "production",
        "source": "customer_backend"
      }
    }
  }'

{
  "ok": true,
  "queued": true,
  "job_id": "decision_123",
  "status": "processing",
  "status_url": "/api/proof/status/decision_123",
  "message": "Proof request accepted"
}

GET /api/proof/status/decision_123
Authorization: Bearer <EVIDENTIA_API_KEY>

{
  "ok": true,
  "status": "completed",
  "job_id": "decision_123",
  "proof_id": "EV-...",
  "verification_url": "https://<domain>/public/verify/EV-...",
  "public_proof_api_url": "/api/public/proofs/EV-..."
}

Share public verification URLs with auditors, customers, or third parties only for proofs that have been intentionally published. During private beta, customer proofs are private by default.

Evidentia does not replace your application logs. Send a payload that references, summarizes, or hashes the decision, then store the returned proof identifiers in your database.

Example code

Start from the repository examples

Use the Node.js / Express example as a base, then adapt it to your backend.

packages/evidentia-node - Node SDK foundation
packages/evidentia-python - Python SDK foundation
cli/evidentia-verify - Verification CLI foundation
docs/postman/Evidentia.postman_collection.json - Postman collection
docs/http/evidentia.http - HTTP examples
examples/node-express/server.js
examples/node-express/.env.example
examples/nextjs-api-route/route.js
examples/python-fastapi/main.py
examples/node-proof-request.js
examples/python-proof-request.py
examples/curl-proof-request.sh
docs/QUICKSTART.md
README_INTEGRATION.md
docs/DEVELOPER_ONBOARDING.md
DEMO_PROOF.md

Stable public demo proof: EV-DEMO-PUBLIC-001. Open the fixed Public Verification page.

System proof: EV-SYSTEM-PROOF-001. Open the System Integrity Proof page to verify Evidentia’s proof generation, anchoring, and verification operations at a structural level.

Fixed demo and system proofs use Solana devnet anchoring. Mainnet, multi-chain verification, and dedicated infrastructure are planned production capabilities and are not self-service during private beta.

During private beta, Developer is the only self-serve plan. Usage limits and rate limits may apply, development blockchain networks may be used, and Stripe billing is not enabled.

Verification export packages are available for public proofs and authorized private proofs; raw AI payloads are not included by default.