API changelog

What changed in the API

Every change to the v1 API, newest first. Nothing here removes or renames a field that already existed; additions only. The reference and the OpenAPI spec always describe the current state.

2026-10-15

Zapier integration (by invite)

  • A ProofLedger integration is on Zapier, private while Zapier reviews it for the public directory. Accept the invite to use it in your own Zaps.
  • Trigger Proof Anchored (registers its webhook, checks every delivery's signature); creates Create Proof From Hash and Create Proof From File (the file is hashed inside the Zap run, only the hash reaches ProofLedger); searches Find Proof by External ID and Verify Hash.
2026-10-15

n8n community node

  • n8n-nodes-proofledger is on npm (install from n8n's Settings → Community Nodes). The ProofLedger node hashes a binary field inside n8n and submits only the hash, or takes a hash you already have, one at a time or 100 per call; it also reads proofs back by ID or external ID, fetches bundles, lists, verifies, and manages webhooks.
  • The ProofLedger Trigger registers a webhook on activation, stores the secret, checks ProofLedger-Signature on every delivery and answers 401 to anything else. Each run gets the proof and its bundle.
  • Two importable workflows ship with it: anchor a file and save <file>.proof.json beside it; one flat item per anchored proof. Source: GitHub.
2026-10-15

Clients and a Postman collection

  • The verify-proof package now carries a ProofLedger API client: Python 0.3.2 on PyPI (submit_proof, submit_batch, get_proof, get_proof_by_external_id, get_bundle, verify_webhook_signature) and Node 0.3.0 on npm (the ProofLedger class and verifyWebhookSignature). Verification stays offline; only the client talks to the API.
  • The MCP server gained batch, status and bundle tools.
  • A Postman collection covers every endpoint, generated from the OpenAPI spec. Set the api_key variable and run the submit request first; it stores the proof id for the rest.
  • The spec gives GET /api/v1/branding an operationId (getBranding) and carries a logo and a link to this reference, for API directories.
2026-10-15

Bitcoin anchoring discontinued

  • ProofLedger no longer anchors to Bitcoin. Every proof is anchored on Polygon, as before. Proofs anchored on Bitcoin before today keep that record on their own certificate and in their bundle.
  • bitcoin_requested is still accepted on POST /api/v1/proof so older clients keep working, and is ignored. In batch items it is refused as invalid, as it always was.
  • Response shapes are unchanged: bitcoin_status reads NOT_REQUESTED, bitcoin_txid and bitcoin_explorer_url are null, evidence_readiness is READY_POLYGON once anchored. proof.bitcoin.anchored stays a valid webhook event name and no longer fires. ?chain=bitcoin on the bundle endpoint only has data for the older proofs.
  • The per-proof Bitcoin checkout answers 410.
2026-10-15

API Terms and subprocessors page

  • The API Terms are now published: an addendum to the Terms of Service for software that records proofs through the API. Creating a key or calling the API accepts them. They set out how proofs may be described, partner branding, data handling, webhooks, the additions-only versioning rule with 90 days' notice for any breaking change, and what happens if the service is discontinued.
  • The subprocessors page lists every provider that handles service data, what each receives and where it runs.
2026-10-15

Per-key rate limit, proof bundles

  • Every call made with an API key is limited to 120 requests per minute per key. Responses carry X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset; over the limit you get 429 with Retry-After. Refused calls do not count toward your monthly cap.
  • GET /api/v1/verify accepts an API key. With one, the key's per-minute limit applies instead of the 120-per-hour per-IP limit.
  • New: GET /api/v1/proof/:id/bundle. One JSON document in the verify-proof file format with the hash, chain, transaction id, anchor time and, for Bitcoin, the Merkle path. ?chain=bitcoin and ?download=1 are optional.
  • Webhook payloads now carry data.bundle next to data.proof.
  • Bitcoin-anchored proofs record when the transaction id was entered (bitcoin_anchored_at in the bundle; older proofs have null there, the block time is on the transaction).
2026-10-14

Partner branding

  • Approved partners get their product name on the certificate and the public verify page: Recorded through <Partner> · Anchored by ProofLedger. Approval is by hand; email support with your product name and website.
  • New: GET /api/v1/branding says what your account's certificates show. Proof objects carry the same value as issued_via.
  • Branded proofs no longer show the account's masked email on public pages.
2026-10-14

Webhooks

  • New: POST /api/v1/webhooks registers an https URL (GET lists, DELETE /:id removes, POST /:id/test sends a test event). Up to 5 active endpoints per account.
  • Events proof.polygon.anchored and proof.bitcoin.anchored, signed with ProofLedger-Signature: t=<unix>,v1=<HMAC-SHA256>, delivered at least once with ProofLedger-Event-Id for deduplication.
  • Retries at 1m, 5m, 30m, 2h, 6h, 12h and 24h. After the eighth failure the endpoint is switched off and the account owner emailed. Only proofs created after the endpoint was registered produce events.
2026-10-14

Batch submission, your own ids, lookup

  • New: POST /api/v1/proofs/batch, up to 100 hashes per call, validated first and written together. Polygon only.
  • external_id on POST /api/v1/proof and in batch items: your own record id, unique per account. Resending it returns the existing proof (200, already_existed: true) instead of creating another.
  • New: GET /api/v1/proofs. Look up by ?external_id=, or list proofs with ?anchored_since=, newest first, cursor paged.
  • Proof objects carry polygon_anchored_at.
2026-10-14

Fixes

  • API proofs whose anchoring attempt failed while the signing service was unreachable are retried automatically. Previously they could stay pending until someone noticed.
  • Bitcoin proofs waiting for the hand-signed batch report bitcoin_status: PENDING. They used to report FAILED.
  • The reference no longer describes keys, limits or endpoints that did not exist. If you integrated against the old text, the current reference is the one to trust.
2026-08-20

API on every plan

  • API keys are issued on every plan, including Free: 25 API proofs a month on Free and Standard, 500 on Professional, 5,000 on Business.