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/check0.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}andrecords.receiptnow return each attempt (an entry the record's rules did not allow, such as one sent afterclosed) and each failure record, with its receipt. Before, they were left out, andrecords.checkand 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, orattemptedTargetandfailureClassin its sealed record.
SDKs
@pacspace-io/sdk0.12.0 addsrecords.disclose, which readsGET /api/v1/records/{recordType}/{record}/disclosure-sourceand 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 413RECORD_HISTORY_TOO_LARGE.@pacspace-io/check0.2.0 checks that file, andpacspace-sdk0.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/sdk0.11.0 andpacspace-sdk0.4.0 carry the records calls these docs use:emit,history,receipt,check, and the fingerprint helper. Both default toapp.pacspace.io.- Entries count from 1 in both SDKs, as every page does:
entry: 1is the first entry, and the SDK converts to the wire'sseqitself. Anentrybelow 1 is refused before anything is sent. Through 0.10.0 and 0.3.0,entrytook the wire's number, counted from 0; if your code passed those, add 1. emittakesamends, the committed entry a correction names, withlifecycle: amended.- A 429 names its wait in
retryAfterSeconds, and both SDKs wait exactly that long before the retry. @pacspace-io/check0.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/recordsare the documented v1 surface. No breaking changes. record.committedandrecord.failedjoin 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_EXCEEDEDwithretryAfterSecondsin the body and aRetry-Afterheader. The Free plan's limit answers 402PLAN_LIMIT_REACHEDwith 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.