Developer Integration Recipe

A safe, observable handoff from a Node workflow

R08 · Runnable local recipe + documented SDK integration · No live API test performed

This is a concrete example of creating a handoff from a support/onboarding worker without putting a reading link in its ordinary output. It is not an installed CRM or helpdesk connector. It does not fetch or expose real customer credentials, deliver messages or implement a replacement crypto protocol.

Run the supplied mock now

With Node 20.19+ (tested locally on Node 22):

cd developer-recipe
node --test recipe.test.mjs
node demo.mjs
node demo.mjs

No package installation or network access is needed for the mock. The first run creates a non-operational training handoff; the second returns the existing receipt without another create. The protected .private-state directory contains the operation journal and encrypted result. The receipt key is co-located only for this local teaching example: this is not a production vault. Use your protected secret facility and durable storage in a real integration. On Windows, configure/test equivalent directory and key-file ACLs before live use; the POSIX checks do not supply Windows isolation.

What is implemented

An exact case/recipient/namespace proposal is validated. An exclusive operation record is written before the create. The result's private reading link is encrypted locally under AES-256-GCM and not emitted in logs or stdout. Repeating the same completed operation returns a safe summary. Changed proposals conflict. Pending/uncertain operations stop for reconciliation rather than minting another handoff. The input value is deliberately fixed training text.

The public response identifies the case, operation receipt and short code. Review even this metadata before putting it in customer-visible fields. An authorized delivery worker can consume the private result in memory; that sender is not supplied or silently enabled.

Optional live disposable test — separate approval

The official Node SDK documents the named CredenShare export, positional credential constructor, shares.create, and expiredAt / accessCountsLeft options. This recipe pins the documented package release 0.1.3, not an assertion that it is the latest. See https://docs.credenshare.io/sdks/node . The SDK encrypts before the create; do not replace it with plaintext API requests.

npm install --save-exact @credenshare/sdk@0.1.3
## Review the dependency and retain the generated lockfile.
## Place an authorized test credential in an owner-only file outside source control.
CREDENSHARE_KEY_FILE=/absolute/protected/test-key.txt node demo.mjs --live --approve-live-create

That is an actual write to the configured account, consumes allowance, and creates a ten-minute disposable share. It sends no customer email. Verify actual shares:write scope, API entitlement, namespace and receipt protection first. Never use a production secret in this fixture. No actual credential or account access is bundled, and the package was not installed or exercised against the live service here.

Resume and failure rules

A crash after POST may leave PENDING while the service has created the share. A transport error may leave UNKNOWN. Do not remove the state file or change the case reference to force a repeat. Reconcile with the responsible operator and the available service metadata. An unresolved reading link may be unrecoverable; let the bounded disposable item expire and document the outcome. Automatic SDK retries are disabled in this example. The source SDK docs warn that a new create call produces new encryption bytes, so it is not a safe logical retry of the old create.

This file journal is a single-host demonstration. Production needs verified atomic durability, resource-level serialization, separate protected key storage, retention, recovery and non-secret monitoring. Local encryption plus a co-located key is not a claim of resistance to a compromised host. The tests cover the recipe's logic and mock interface—not the SDK's own conformance or a live customer flow.

Integrate into existing work

Reuse an existing authorized worker. Bind the case and recipient server-side. Replace only the fixed training value with a permitted secret source after review; never accept arbitrary secrets in CRM fields or model prompts. Give the restricted delivery component the decrypted link only for an approved route. Keep source-system access closure as an independent owned action. No new middleware product or CRM model is needed solely for this example.