Skip to content

Prove it later

Everything Planisphere seals is built to be re-checked by someone who does not trust you — or us. This page is the export-and-verify path: pull the records for a period, bundle them, and verify the bundle anywhere.

Export a time range

GET /tenant/exports/records?from=&to=&cursor= returns the sealed records for a period. Filters are always applied — unknown query parameters are rejected, never silently ignored — so an export is exactly what you asked for.

curl -sS "https://api.planisphere.ooo/tenant/exports/records?from=2026-07-01T00:00:00Z&to=2026-08-01T00:00:00Z" \
  -H "X-Planisphere-Key: ps_test_YOUR_KEY"

Page through with cursor until it comes back empty, collecting each record's action_key.

Bundle the evidence

POST the action keys to POST /evidence-packets/seal-bundle/batch as a wrapped object — {"action_keys": [...]}, unlike the bare array POST /v1/record/batch takes — and you get one offline-verifiable evidence package for the whole set:

curl -sS -X POST https://api.planisphere.ooo/evidence-packets/seal-bundle/batch \
  -H "X-Planisphere-Key: ps_test_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"action_keys":["law:proposed-action:…","eu-ai-act:record:…"]}'

Verify — three ways

  1. Online: POST /v1/verify with a record's verify request — every seal check itemized: signature, hashes, and key identity, each recomputed. The gate/review/record response carries an in-band verify_request, and quickstart step 5 walks the whole round trip.
  2. Offline recipe: GET /v1/verify/kit returns the verification recipe — fields, hashes, and checks, no key material required — so an auditor can re-derive every check themselves.
  3. In the browser: www.planisphere.ooo/verify verifies seal-bundle files entirely in your browser; the record data never leaves the tab.

The trust anchor is public: /.well-known/planisphere-keys.json publishes the signing keys, so verification never depends on asking Planisphere whether Planisphere is honest.

Payload retention

Planisphere stores hash commitments only — it never holds your content. Retain your payload to re-prove WHAT was recorded; the sealed record proves THAT it happened and that nothing was altered. Every record response repeats this in its payload_retention field.