Skip to content
PacSpace
Talk to us

Changelog

Notable changes to the records API, the SDKs, and this documentation.

Notable changes to the API surface, the SDKs, and these docs. Additive changes ship continuously and are not listed one by one; anything that changes how you integrate appears here. See API stability and versioning for what can and cannot change within v1.

October 2026

Docs

  • Worked examples for each reader: an agent in an evaluation, an evaluator checks the record, and a claims agent and the person who decides, beside the existing three, with an overview. The old address of "Records handed to another organization" redirects to the evaluator's example.
  • For the person you share with is written for evaluators, auditors and oversight offices: what they get, what the check shows and does not, and what to ask the sender for.
  • Fingerprinting the same file again gives a different fingerprint, because fingerprints are blinded. The examples now reuse the file's blinding file, so a retry sends the same body. See Safety and idempotency.
  • The SDKs need Node 20.19 or later. A 401 carries no error code; the SDKs raise InvalidApiKeyError.
  • The checker's word for where it reads a record's seals is "the proof layer", the infrastructure no party controls where each seal is committed, as @pacspace-io/check 0.2.1 prints it: "Compared with the proof layer for this record: it matches."

API

  • Shared Record links show seals by default. A new records link shows each entry's seal and none of what it says. From the dashboard's share card you can reveal, for each entry, chosen fields or every field; the link carries them encrypted, opened by the part of its address after #. Revealing fields makes a new link and revokes the old one. Links made before this change keep showing each entry's words. New error codes when the dashboard adds revealed fields to a link: RECORDS_DISCLOSURE_TOO_LARGE, RECORDS_DISCLOSURE_MALFORMED, RECORDS_DISCLOSURE_NOT_ACCEPTED, RECORDS_DISCLOSURE_NEEDS_ACCESS_CODE.
  • A record's history carries its attempts and failure records. GET .../history, records.history, GET .../receipts/{seq} and records.receipt now return each attempt (an entry the record's rules did not allow, such as one sent after closed) and each failure record, with its receipt. Before, they were left out, and records.check and the checker reported such a record's history as incomplete. The history file's shape is unchanged. To tell these entries apart, read the flags in the entry's word, or attemptedTarget and failureClass in its sealed record.

SDKs

  • @pacspace-io/sdk 0.12.0 adds records.disclose, which reads GET /api/v1/records/{recordType}/{record}/disclosure-source and builds a file that reveals the fields you choose, checked against the public ledger; a record with more than 5000 entries on the ledger answers 413 RECORD_HISTORY_TOO_LARGE. @pacspace-io/check 0.2.0 checks that file, and pacspace-sdk 0.5.0 checks each field it shows against the record's seal history inside it.

September 2026

Docs

  • These docs now describe the records API from the front door in: what you can record, the quick start, writing an entry, history, receipts, the check, the Shared Record, verification, the SDKs, webhooks, recording from an agent, three worked examples, and the reference.
  • One host. Every request goes to app.pacspace.io; the key decides whether it writes to Sandbox or Production.
  • The pages that described metering and settlement are removed, with their examples. Their addresses redirect to the nearest records page.
  • The Dashboard API pages cover authentication, API keys, webhook endpoints, the workspace, environments, the team, and the plan.
  • A fourth worked example, Correcting an entry.

SDKs

  • @pacspace-io/sdk 0.11.0 and pacspace-sdk 0.4.0 carry the records calls these docs use: emit, history, receipt, check, and the fingerprint helper. Both default to app.pacspace.io.
  • Entries count from 1 in both SDKs, as every page does: entry: 1 is the first entry, and the SDK converts to the wire's seq itself. An entry below 1 is refused before anything is sent. Through 0.10.0 and 0.3.0, entry took the wire's number, counted from 0; if your code passed those, add 1.
  • emit takes amends, the committed entry a correction names, with lifecycle: amended.
  • A 429 names its wait in retryAfterSeconds, and both SDKs wait exactly that long before the retry.
  • @pacspace-io/check 0.1.1 checks a history file without a key and without PacSpace, and its count line says what the check confirms: "All 3 are here, and all 3 match what was committed."

API

  • The records routes under /api/v1/records are the documented v1 surface. No breaking changes.
  • record.committed and record.failed join the webhook event set.
  • Amendments are on: a correction is a later entry that names the entry it corrects. Refusals: RECORD_AMENDS_NOT_FOUND, RECORD_AMENDS_NOT_PRECEDING.
  • Every 429 is RATE_LIMIT_EXCEEDED with retryAfterSeconds in the body and a Retry-After header. The Free plan's limit answers 402 PLAN_LIMIT_REACHED with a plain sentence.
  • A retention window never removes any part of a record.
  • Every API key is Sandbox or Production, chosen when it is made.

July 2026

Docs

  • Documentation moved to docs.pacspace.io, on the PacSpace design system.
  • Code examples use language tabs (TypeScript, Python, cURL) across the API reference and examples.
  • New pages: API stability and versioning, and this changelog.

API

  • The v1 surface documented on this site is stable. No breaking changes.

Entries begin July 2026, when this changelog was introduced. Questions about earlier behavior: contact us from the footer.