Vault protection guide

External custodians: connect and store journal records

Confirm integration readiness, stage encrypted journal copies and automatically save finalized PDFs with supporting evidence.

Updated October 29, 20265 min read

← All vault guides

Follow this path if you manage the external custodian's integration. You retain the complete source record, encrypt the assigned notary's copy and operate the service that saves finalized PDFs. Workspace admins approve access; each notary controls their own journal key and finalization decision.

1. Confirm workspace access and notary enrollment

Have each assigned notary complete private journal setup. Check Team → Teammates → Journal key setup in the admin enrollment check. The external custodian retrieves that notary's current public encryption key, associated key ID and workspace assignment. It never needs the journal password, private key or recovery secret. The copied public key or the external custodian's authorized key lookup is for encryption, not a replacement for notary review.

Ask the external custodian to verify these items together: the correct workspace/client, active assigned notary, commission, current enrolled public key and approved company origin. Do not allow an unprotected fallback if the notary has not enrolled a usable key.

2. Connect your service

Use Set up automatic journal PDF storage for the technical implementation: authorization, public-key lookup, encrypted-copy storage and staging, finalization notifications, verification and automatic archival. Use the environment's Developer docs link for exact request contracts and permissions.

Wait for the admin handoff: workspace API approval, an enabled integration and client, securely supplied credentials and a saved portal origin must be ready before sending entries. Do not use the notary's login or private journal password as integration credentials.

For a local practice environment only: the external custodian’s integration operator can start the synthetic company app from tui.sh → Command Launcher → Services → Customer journal app: Start, then open http://localhost:18716. Starting that app alone does not approve the origin. The local backend must also support the approved-origin setting and explicitly allow loopback HTTP. A missing control, 404 or HTTPS-required error needs the environment administrator; changing unrelated account permissions will not fix it. Do not use the synthetic service for real signer data.

To check local dependencies first, use tui.sh → Command Launcher → Setup Check → Federated Journal: Check local services. A healthy service check does not confirm workspace approval, key enrollment or successful PDF storage.

3. Stage a synthetic practice entry

The external custodian creates the complete synthetic source record in its own system, encrypts a copy for the assigned notary and stages the permitted metadata and commitment through the API. Keep the complete source snapshot and salt with the external custodian. Store the notary’s encrypted copy independently in NotaryCentral before staging is accepted. Document type and associated notarial-act details stay in that external complete record; the NC Entry Details panel is metadata-only.

There is no company Stage button to press. There is also no company-side Finalize button. The notary will make the final decision in NotaryCentral. Give them the opaque order/entry reference so both sides can identify the same practice record without sending signer data through chat.

Expected result: the assigned notary sees a review banner and the entry in their own commission's Journal → Drafts. Ask the notary to follow their review and finalization steps, then reopen the protected copy for the practice check. Confirm the company worker automatically saves the complete PDF. When the one-entry check succeeds, practice a small batch: inspect the records, select the intended drafts and check every result. Leave one unselected to confirm it stays a draft.

For request contracts, staging permissions and idempotent retries, follow the technical guide linked in step 2. Notaries do not need to run integration commands.

4. Save finalized PDFs and supporting evidence

Company PDF storage is automatic once the integration is configured. Your company’s archive worker uses its own historical source data and signed evidence to verify, render and save the complete PDF with supporting evidence. This does not grant an NC administrator access to the notary's decrypted protected copy or supply an organization archive browser inside NC. See the integration guide for worker and storage setup. No notary secret is needed.

If organization archival is pending, the entry is still finalized. The external custodian checks its OAuth, exact source version, trust root, assets, renderer, storage and acknowledgment. Its worker retries incomplete archival. Refresh the status when needed; do not create another entry or ask the notary to unlock a viewer merely to recover delivery.

Confirm the storage destination

Your company’s archive worker saves journal.pdf, journal.json and manifest.json in the company’s chosen storage. In the local demo these appear under ~/.local/share/notarycentral/customer-journal-demo/archives/, inside the exact journal/version/receipt .export folder. Production uses the company’s approved storage destination. A healthy local worker normally saves within a few seconds; check successful package storage and acknowledgment rather than assuming a fixed delay proves delivery.

The notary may close the app after finalization succeeds. Your company’s PDF processing continues in the server worker. The notary’s private-copy workflow is separate from company PDF storage.

5. Check storage and resolve integration problems

  • Confirm the exact workspace/client, assigned notary, commission, enrolled public key and approved portal origin before creating the protected copy.
  • Confirm the independent encrypted notary copy is stored before staging is accepted.
  • After the notary finalizes, verify the exact historical source version and signed evidence.
  • Confirm journal.pdf, journal.json and manifest.json were saved, then acknowledge archival.
  • Retry the same receipt/version after a failure; do not create a duplicate entry or ask the notary to finalize again.
  • Record the storage destination and the integration operator responsible for recovery.

Entry creation or staging fails: confirm admin access approvals and notary enrollment. Check the exact error before changing settings. Do not fall back to sending readable journal contents.

PDF archival is pending: inspect authorization, source-version availability, evidence verification, rendering, storage and acknowledgment. A successful webhook response alone does not prove the PDF was saved. Use the failure-recovery steps in the technical integration guide; the notary's entry remains finalized while archival is retried.

Get help without sharing journal secrets.