ProofSnap API-Dokumentation

Die ProofSnap API lädt jede URL in einem Browser auf den Servern von ProofSnap und liefert ein versiegeltes Beweispaket: Screenshot, Seiten-HTML, Metadaten, ein Beweis-PDF und ein SHA-256-Manifest, signiert mit RSA-4096 und verankert mit OpenTimestamps. Basis-URL: https://api.getproofsnap.com/v1. Authentifizierung per API-Schlüssel als Bearer-Token. Stand: Oktober 2026.

Die Beispiele unten lesen die Basis-URL aus einer Shell-Variablen: export PROOFSNAP_API_BASE=https://api.getproofsnap.com/v1

Erste Schritte

1
API-Schlüssel erstellen

Melden Sie sich im Dashboard an, öffnen Sie „Entwickler“ und dann „API-Schlüssel“ und erstellen Sie einen Schlüssel. Er wird nur ein einziges Mal angezeigt. Bewahren Sie ihn daher sicher auf. Schlüssel beginnen mit ps_live_ oder ps_test_.

Erste Aufnahme anfordern

Übergeben Sie den Schlüssel als Bearer-Token. Die API antwortet sofort mit 202, einer capture_id und status: "processing".

curl -X POST "$PROOFSNAP_API_BASE/captures" \
  -H "Authorization: Bearer ps_live_..." \
  -H "Content-Type: application/json" \
  -d '{"url": "https://example.com"}'

3
Ergebnis abrufen

Fragen Sie GET /captures/{capture_id} ab, bis status den Wert completed oder failed hat. Eine abgeschlossene Aufnahme enthält package_url (einen vorsignierten ZIP-Link, bis zu 24 Stunden gültig) und manifest_hash. Für einen neuen Link rufen Sie die Aufnahme erneut ab. Statt den Status abzufragen, können Sie options.webhook_url auf einen HTTPS-Endpunkt setzen. Sie erhalten dann ein mit HMAC-SHA256 signiertes Ereignis capture.completed oder capture.failed.
```
curl "$PROOFSNAP_API_BASE/captures/cap_..." \
  -H "Authorization: Bearer ps_live_..."
```
4
Paket prüfen

POST /captures/{capture_id}/verify prüft jeden im Manifest aufgeführten SHA-256-Hash und die RSA-4096-Signatur des Manifests erneut anhand der gespeicherten Dateien und liefert match, modified oder invalid. Zusätzlich kann jeder die Skripte im Ordner verification/ des Pakets offline ausführen oder den SHA-256-Hash von manifest.json mit GET /ledger/{hash} im Ausstellungsregister nachschlagen. Für beides ist kein API-Schlüssel nötig.
```
curl -X POST "$PROOFSNAP_API_BASE/captures/cap_.../verify" \
  -H "Authorization: Bearer ps_live_..."
```

Authentifizierung

Senden Sie den API-Schlüssel im Header Authorization: Bearer ps_live_.... Schlüssel beginnen mit ps_live_ oder ps_test_. Ein Live-API-Schlüssel erzeugt kostenpflichtige Aufnahmen; ein Testschlüssel erzeugt vollständige, mit Wasserzeichen versehene Evaluierungspakete, die nicht berechnet werden. Ein Live-API-Schlüssel in einem Konto ohne eingerichtete Abrechnung verhält sich wie ein Testschlüssel. Ein fehlender Schlüssel führt zu 401 MISSING_API_KEY; ein unbekannter oder widerrufener Schlüssel führt zu 401 INVALID_API_KEY. API-Schlüssel im Tarif Website Archive sind schreibgeschützt (403 PLAN_API_READ_ONLY). Drei Routen benötigen keinen Schlüssel: GET /health, GET /ledger/{hash} und GET /matter-verify.

Ein neues Konto startet in der Sandbox mit 50 kostenlosen Testaufnahmen. Die Nutzung im Testmodus ist auf 200 Einheiten pro Konto und UTC-Tag begrenzt (429 TEST_MODE_DAILY_LIMIT), Pakete tragen das Wasserzeichen „TEST - NOT FOR LEGAL USE“, und include_eidas erfordert einen Live-API-Schlüssel (403 EIDAS_REQUIRES_LIVE_KEY).

Webhooks

Setzen Sie options.webhook_url pro Anfrage, oder legen Sie mit POST /webhook-subscriptions Webhook-Abonnements auf Kontoebene an. Zustellungen folgen dem Standard-Webhooks-Format: die Header webhook-id, webhook-timestamp und webhook-signature (v1, gefolgt von einem HMAC-SHA256 über ID, Timestamp und Body mit einem whsec_-Secret). Ereignistypen: capture.completed, capture.failed, capture.anchor_confirmed, certify.completed, certify.failed, redaction.completed, redaction.failed, monitor.change_detected und schedule.paused. capture.anchor_confirmed und schedule.paused gehen ausschließlich an Abonnements auf Kontoebene. Jedes Ereignis wird außerdem 30 Tage lang in GET /events vorgehalten. Jeder Zustellversuch bricht nach 10 Sekunden ab; eine fehlgeschlagene Zustellung wird nach 5 Minuten, 30 Minuten, 2 Stunden, 8 Stunden und 24 Stunden erneut versucht. Wenn Sie das Signatur-Secret rotieren, werden Zustellungen 24 Stunden lang sowohl mit dem alten als auch mit dem neuen Secret signiert.

Zustellungen an eine webhook_url pro Anfrage werden mit dem Signatur-Secret des API-Schlüssels signiert, mit dem die Anfrage gestellt wurde. Dieses Secret wird einmalig angezeigt, wenn Sie den Schlüssel im Dashboard unter „Entwickler“ erstellen. Ein Abonnement hat ein eigenes Signatur-Secret, das beim Anlegen einmalig zurückgegeben wird. Prüfen Sie die Signatur anhand des unveränderten Bodys, bevor Sie ihn parsen, lehnen Sie jeden webhook-timestamp ab, der um mehr als 5 Minuten von Ihrer Serverzeit abweicht, und verarbeiten Sie jede webhook-id nur einmal. Jede Standard-Webhooks-Bibliothek erledigt das für Sie.

Rate-Limits und Fehler

Kostenpflichtige Anfragen (POST /captures, /captures/batch, /compare, /captures/{capture_id}/redact und /certify-hash, dazu Prüfungen, Löschsperren, Export-Jobs und Importe) sind pro Konto in festen 60-Sekunden-Fenstern begrenzt, gemeinsam für alle API-Schlüssel des Kontos und dessen Dashboard-Sitzung. Ein Batch oder eine Zertifizierung mehrerer Hashes verbraucht eine Einheit pro URL oder Hash. Einheiten pro Fenster: Sandbox 10, Developer 60, Startup 120, Growth 300, Legal Solo 60, Legal Company 120, Website Archive 60, Archive only 30. Antworten dieser Routen enthalten die Header RateLimit-Policy und RateLimit sowie die älteren X-RateLimit-*-Header; eine 429-Antwort enthält zusätzlich Retry-After.

Live-Aufnahmen werden auf das monatliche Kontingent des Tarifs angerechnet (402 QUOTA_EXCEEDED); Anfragen von einem Konto mit überfälliger Zahlung führen zu 402 PAYMENT_REQUIRED. Jedes Konto kann nur eine begrenzte Zahl von Aufnahmen gleichzeitig ausführen (429 CONCURRENT_CAPTURE_LIMIT). Senden Sie einen Idempotency-Key-Header, damit eine Wiederholung innerhalb von 24 Stunden das ursprüngliche Ergebnis mit Idempotent-Replay: true zurückgibt, statt eine zweite Aufnahme anzulegen. Fehler werden als JSON mit error.code, error.message und, wo sinnvoll, error.details zurückgegeben; nennen Sie den Wert des Antwort-Headers X-Request-ID, wenn Sie den Support kontaktieren. Die vollständige Liste der Codes finden Sie in der Referenz unten.

Endpunkte im Überblick

Aufnahmen: POST /captures, POST /captures/batch (2 bis 50 URLs), GET /captures, GET /captures/hosts, GET /captures/{capture_id}, PATCH und DELETE /captures/{capture_id}, POST /captures/{capture_id}/verify
Auswertung: POST /captures/{capture_id}/redact, POST /compare, POST /certify-hash (bis zu 100 Hashes)
Automatisierung: /scheduled-captures (mit /runs), /webhook-subscriptions, GET /webhook-events/{capture_id}, GET /events, GET /captures/events
Kanzleifunktionen: /matters (Versiegeln, Export, Freigabe), POST /legal-holds, /imports, /captures/export-jobs
Konto und öffentliche Routen: GET /whoami, GET /health, GET /ledger/{hash}, GET /matter-verify

Vollständige Referenz

Alle Endpunkte mit ihren Parametern, Antworten und Schemas, generiert aus der OpenAPI-3-Spezifikation. Laden Sie die Spezifikation als openapi.json (englisch, für Code-Generatoren) oder openapi-de.json (deutsche Beschreibungen) herunter. Ein offizielles SDK gibt es nicht: Erzeugen Sie einen Client mit einem beliebigen OpenAPI-3-Generator, und prüfen Sie Webhooks mit einer beliebigen Standard-Webhooks-Bibliothek.