In the company-managed journal workflow, your organization retains historical signer data and assets. NotaryCentral manages permitted journal metadata, personal finalization, signed evidence and an independently stored encrypted notary copy. Your worker verifies the matching historical record, renders the complete PDF and stores it in your environment.
For the complete setup sequence, use Set up automatic journal PDF storage. For account screens and private key enrollment, use the admin and notary handbook.
1. What belongs on each side
| NotaryCentral | Your company’s environment | Notary's isolated personal viewer |
|---|---|---|
| Permitted metadata, journal/version IDs, client/workspace binding, commitments, signed receipts and encrypted notary copies | Exact historical snapshot bytes, salts, source assets, encrypted notary copies, complete PDFs and evidence packages | Private passphrase use and decryption of the notary's protected copy |
Company source data, commitment salts, encrypted packages and complete PDFs are not accepted as journal staging payloads. Opaque references still require access control. This boundary applies to the company-managed journal workflow; it does not claim that every signing, identity, billing or other service processes no personal information.
V2 commitments cover the exact retained UTF-8 snapshot bytes and their length. Use the versioned protocol helpers rather than a homemade hash or a reserialized copy of the source. NotaryCentral signs a receipt binding that commitment and the metadata digest; it does not sign or inspect a PII-filled PDF.
2. Configure the workspace and the specific client
A workspace owner/admin first confirms workspace API approval in Menu → Settings → API credentials, with the correct Credential workspace selected. Personal API approval is separate.
Enable Federated journal integration in Team → Settings → Journal. Keep the workspace integration, API access and intended OAuth client enabled. The client needs the Create, Commit and Read evidence federated-journal permissions described in the integration guide.
The integration toggle permits the authorized API workflow. It does not enroll personal keys, protect earlier entries or authorize an API client to make the assigned notary's Finalize decision. Disabling access does not delete existing evidence or company-managed files.
Require Vault protection for all workspace members is a separate policy. Each applicable notary still enrolls their own key. Admins check readiness and share authorized public encryption material; they do not receive private keys, passwords or recovery kits.
3. Approve the company portal origin
On the intended client under Existing clients, set your company’s approved portal origin and save it. The admin handbook maps this term to the exact labels in existing app versions. Use an exact origin such as https://portal.example.com: scheme, host and optional port only. Do not include a record path, credentials, query parameters or wildcards.
The provider supplies an individual external_record_url beneath that origin when creating the entry. Each entry retains its immutable company/client/workspace binding. Saving a different origin applies to new entries; it does not redirect old records or make another provider's records accessible.
Expected result: save confirmation, followed by the same value after refresh and workspace reselection. A missing origin or an entry URL on another origin stops protected creation. Loopback HTTP is a separately enabled development exception, not a production portal setting.
The older workspace custody configuration may also show PII data custodian, Source portal HTTPS origin and an Order lookup URL template. The template uses one opaque {externalOrderRef} beneath the approved source origin. These workspace fields describe custody/navigation; they do not replace per-client origin approval in the company-managed flow. A custodian label may be included in signed evidence where configured; do not assume every PDF template prints it or that a setting is proof of regulatory approval.
This earlier configuration image illustrates workspace custody fields. Follow the current per-client portal steps for protected company-managed entries.
4. Configure evidence checks
The portal serves authorized source records to people. Your company’s worker separately checks the evidence API using the owning workspace-bound OAuth client and Read evidence permission.
Retain the journal IDs or external order references created by your integration. Reconcile them through evidence history or batch retrieval, then queue each finalized receipt and exact journal version for verification and PDF creation. Preserve progress across restarts and reuse completed work for the same receipt/version.
5. Finish with a stored complete PDF
After the notary's personal Finalize selected action:
- Your worker retrieves the exact signed receipt/version through the evidence-history API.
- It verifies the receipt and its own frozen source snapshot against the independently provisioned trust root and commitments.
- It renders the complete journal PDF in your company’s environment and saves the PDF, evidence JSON and content-hash/renderer manifest.
- After durable storage succeeds, it sends the scoped, idempotent receipt acknowledgment to NotaryCentral.
The company workflow needs no browser, Download click or notary passphrase. The notary’s personal viewer retrieves their independently stored encrypted copy from NotaryCentral. It requires no company login or contact with the original company, including after the notary leaves the organization. Source retrieval, signature assets, renderer, OAuth renewal and storage must be working before an integration reports archival complete.
The local reference demo writes private files; your production deployment uses its own approved object store. A worker outage or failed PDF save leaves the entry finalized and archival pending. Use durable retry and authenticated reconciliation, including records finalized before the worker started. Never create another entry simply to resend a receipt.
Questions to settle before onboarding
- Does approving the portal enable automatic PDFs?
No. Portal approval binds authorized record navigation. Your integration team configures evidence checks, the verification/rendering worker, storage and acknowledgment. Follow the end-to-end integration guide.
- Does the company need each notary's private password?
No. It renders from the historical data it already holds and the signed evidence retrieved through OAuth. A notary uses their own password only for their separate protected copy.
- Where does the complete PDF live?
In company-controlled storage. The reference demo uses a private local archive directory. NotaryCentral receives the receipt acknowledgment, not the source snapshot or completed PDF.
- What should we verify before real records?
Prove one synthetic entry end to end, inspect its complete PDF, repeat the evidence check, test company-service restart and storage failure, and confirm that acknowledgment waits for successful storage. The integration guide includes the full acceptance checklist.